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1  Introduction 

This  report  describes  the  work  performed  by  SRI  International  and  its  subcon¬ 
tractor  Stanford  University  on  contract  F30602-93-C-0245,  dealing  with  formal 
definition  of  software  architectures  to  support  system  composition.  Our  basic 
approach  to  architecture  definition  is  presented  in  Section  2,  while  Section  3  out¬ 
lines  the  work  performed  on  this  particular  project.  The  details  of  our  efforts 
can  be  found  in  the  appendices. 
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Figure  1:  The  SRI-Stanford  Approach  to  Architecture  Definition 


2  Formal  Architecture  Definition 

The  Software  Architectures  team  at  the  SRI  Computer  Science  Laboratory 
(CSL)  and  the  Program  Analysis  and  Verification  Group  (PAVG)  at  Stanford 
University  are  engaged  in  a  joint  effort  to  develop  concepts  and  tools  for  formally 
defining  software  architecture  hierarchies.  Figure  1  illustrates  our  approach. 

The  box  in  the  upper  left  corner  of  the  figure  illustrates  the  structure  of 
a  typical  Sadl  architecture  hierarchy.  The  most  abstract  specification,  S(), 
is  the  root  of  a  tree  in  which  each  node  is  a  Sadl  architecture  specification 
and  each  arrow  is  a  Sadl  mapping.  An  architecture  hierarchy  need  not  be  a 
tree.  Any  partial  order  is  perfectly  acceptable.  But  developing  an  architecture 
hierarchy  by  top-down  refinement  will  produce  a  tree.  The  three  successors  of 

—  i.e.,  S(o>,  S(i),  and  S(2)  —  represent  three  alternative  ways  of  making 
the  abstract  S()  architecture  somewhat  more  concrete.  Focusing  on  the  leftmost 
branch  of  the  tree,  architecture  S^oo)  is  a  further  refinement  of  architecture  S(o>, 
architecture  S^ooo)  is  a  further  refinement  of  architecture  S(oo>i  and  so  on  down 
to  S(ooo).a)  an  implementation-level  architecture  that  is  a  refinement  of  all  its 
ancestors.  Generally,  in  this  tree-shaped  hierarchy,  specifications  are  indexed  so 
that  S<T  is  an  ancestor  of  S,-  if  and  only  if  cr  is  an  initial  subsequence  of  r  (i.e., 
if  and  only  if,  for  some  finite  sequence  p,  t  =  cr  ■  p). 

The  box  in  the  upper  right  corner  of  the  figure  contains  a  pair  of  executable 
Rapide  architecture  protocol  simulations.  Each  Rapide  architecture  corresponds 
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to  one  of  Sadl  architectures,  as  indicated  by  the  heavy  doubleheaded  arrows 
(and  matching  indices).  This  correspondence  is  not  formally  specified.  Each 
architectural  specification  contains  information  the  other  does  not.  The  Rapide 
specification  contains  behavioral  information  required  for  simulation  that  is  typ¬ 
ically  irrelevant  to  the  Sadl  structural  specification,  and  which  is  therefore  omit¬ 
ted.  The  Sadl  specification  encodes  details  about  the  logical  strength  of  the 
architectural  styles  being  employed,  details  that  are  crucia,!  to  the  analysis  of  re¬ 
finement  correctness,  and  that  are  not  expressible  in  Rapide.  Someone  familiar 
with  both  languages  can  easily  judge  whether  a  Sadl  architecture  and  a  Rapide 
architecture  “correspond”,  in  other  words,  whether  they  consistently  describe 
a  system,  at  the  same  level  of  abstraction,  but  from  differing  perspectives.  For 
these  reasons,  formalizing  the  correspondence  as  opposed  to  relying  on  con¬ 
vention,  such  as  using  the  same  name  for  corresponding  components  —  would 

be  of  little  utility.  * 

The  two  Rapide  architectures  in  the  figure  are  linked  by  a  Rapide  event 
mapping.  Any  number  of  Sadl  architectures  can  have  corresponding  Rapide 
architectures.  This  event  mapping  is  partially  determined  by  composing  the 
Sadl  mappings  that  link  the  corresponding  Sadl  architectures.  In  the  figure, 
the  architectural  protocols  are  simulated  at  both  an  abstract  level  in  X(2) 
at  a  quite  concrete  (implementation)  level  in  X(2oi).5- 

The  lower  box  shows  implementations  of  some  of  the  most  concrete  Sadl 
architectures,  linked  to  their  specifications  by  a  mapping  expressed  in  a  pro¬ 
gramming  language-specific  extension  of  Sadl’s  mapping  language.  (An  ex¬ 
tension  for  Java  is  under  development.)  In  this  example,  only  two  of  the  five 
implementation-level  Sadl  architectures  have  been  instantiated  as  code.  The 
dashed  arrow  from  X<2oi>  £  to  I<20i>  e  indicates  a  nonformalized  mapping  of  the 
Rapide  simulation  of  the  architectural  protocols  to  an  implementation  of  those 
protocols  in  the  instantiation.  The  feasibility  of  replacing  this  dashed  a,rrow  by 
automatic  code  generation  —  based  on  an  implicit  formal  mapping  is  under 
investigation. 

The  approach  to  formal  definition  of  architectures  described  above  provided 
the  foundation  for  the  research  performed  for  this  project.  More  detail,  including 
motivations  for  creating  a  hierarchy  and  the  advantages  of  doing  so,  can  be  found 
in  the  appendices  (Appendix  B,  in  particular). 
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3  Results  of  this  Effort 
3.1  SRI 

Prior  to  this  project,  SRI  CSL  had  developed  a  formal  architecture  definition 
system,  called  PegaSys,  for  a  commercial  client.  PegaSys  addresses  a  very  special 
case  of  the  general  problem  addressed  by  Sadl.  In  PegaSys,  only  two  styles  of 
architectural  specification  were  supported.  An  architecture  could  be  specified  at 
an  abstract  level  using  a  dataflow  style,  or  at  a  concrete  level  using  reading  and 
writing  of  arrays  of  variables  and  control  signals  to  implement  dataflow.  These 
two  styles  were  already  being  used  for  informal  architectural  specification  by 
the  customer.  PegaSys  hierarchies  thus  had  a  very  simple,  restricted  structure: 
refinements  either  replace  a  component  by  a  collection  of  connected  components 
(“bubble  decomposition”)  or  implement  dataflow.  PegaSys  tools  checked 

•  the  syntactic  correctness  of  specifications, 

•  whether  type  constraints  on  connections  were  satisfied,  and 

•  whether  refinements  could  be  verified  by  creating  a  combination  of  some 
h2irdwired  refinement  patterns  that  matched  the  refinement  step. 

This  system  proved  useful  in  practice.  Several  bugs  were  found  in  the  archi¬ 
tectural  descriptions  of  large  (100,000  to  1,000,000  lines  of  source  code)  control 
systems  by  formalizing  those  descriptions  in  the  PegaSys  language  and  checking 
them  with  the  PegaSys  tools. 

The  meiin  emphasis  in  the  present  project  was  on  gener2ilizing  PegaSys  to 
deal  with  other  domains  —  additional  architectural  styles,  more  complicated 
hierarchies,  and  so  on  —  and  replacing  the  ad  hoc,  informal  notion  of  hier£irchy 
correctness  employed  in  PegaSys  by  a  more  precise  criterion.  PegaSys  specifica¬ 
tions  can  be  converted  to  Sadl  specifications  with  relatively  little  change,  but 
Sadl  is  a  far  richer  lernguage.  In  addition  to  particular  architectures,  Sadl  can 
be  used  to  define  constraints,  generic  architectures,  styles,  mappings  between  ar¬ 
chitectures  and  between  styles,  zind  refinement  patterns.  See  the  Sadl  manned, 
available  on  the  web  at 

<http : / /www . csl . sr i . com/sadl/ sadl-intro . ps . gz> 
for  details. 

The  Sadl  extensions  were  driven  by  an  analysis  of  exeimples.  Both  simple 
particular  architectures,  such  as  the  compiler  architecture  used  in  the  paper  in¬ 
cluded  as  Appendix  B  of  this  report,  and  complex  generic  architectures,  such  as 
X/Open’s  Distributed  Transaction  Processing  (DTP)  standard  architecture  de¬ 
scribed  in  Figure  2,  were  formalized  in  Sadl.  The  result  of  formalizing  X/Open 
DTP  has  been  included  as  Appendix  A. 

Once  the  language  design  stabilized,  tool  development  beg£in.  The  Sadl  1.0 
software  distribution,  available  at 

<http : //www . csl . sri . com/sadl/sadl-distribution . tar . gz> 
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Dataflow  Architecture 


X/Open  DTP  Reference  Architecture 
(procedure  call) 


rendezvous 
(blocking  RPC) 
on  AR  interface 


synchronous 
(non-blocking  RPCs) 
on  AR  Interface 


asynchronous 
(buffered  RPCs) 
on  AR  interface 


“two  RM“  instantiation 

1  X/Open  RA; 
1  Rapide  Executable  RA: 
17  Sadl  Structural  Designs: 


“generic"  RPCs 
on  AR  interface 

A 

Four  refinements  of 
AP,  TM,  and  RM 
internals  (for 
process  allocation) 


>400  pages 
20  pages 

42  pages  (-30  design  patterns) 


Figure  2:  The  X/Open  DTP  Architecture  Hierarchy 


contains  a  parser,  printer,  and  mapping  checker  for  the  language.  See 

<http : //www . csl . sr i . com/sadl/README . html> 

to  get  an  idea  of  the  toolset’s  present  capabilities. 

The  result  of  our  attempt  to  define  a  formal  correctness  criterion  for  architec¬ 
ture  structure  hierarchies  can  be  found  in  Appendix  B.  (Appendix  C  shows  how 
an  external  semantics  can  be  provided  for  connector  types,  which  can  be  useful 
both  for  explanation  and  for  showing  the  consistency  of  the  Sadl  constraints 
that  internally  define  a  connector  type.) 

3.2  Stanford  University 

Prior  to  this  effort,  Stanford  PAVG  developed  the  Rnpide  language  as  a  general 
simulation  tool.  On  this  project,  PAVG  researchers  showed  how  Rapide  can 
be  used  for  architectural  definition,  by  formalizing  complex  architectures,  and 
extended  the  capabilities  of  the  toolset. 

The  Rapide  toolset  can  be  found  at 

<http : //anna . Stanford . edu/rapide/tools-release . html> 
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4  Conclusions 


Our  principal  objective  in  this  contract  was  used  to  demonstrate  the  utility  of 
the  basic  approach  to  architecture  definition  described  in  Section  2.  We  believe 
that  this  objective  was  satisfied  by  fully  formalizing  a  complex  axchitectureil 
hierarchy  involving  features  —  such  as  a  variable  number  of  components  — 
that  other  architecture  definition  languages  cannot  handle  in  any  straightfor¬ 
ward  fashion,  by  formalizing  the  notion  of  hierarchy  correctness  so  that  the 
precise  benefits  of  correctness  are  clear,  and  by  developing  our  toolsets  to  the 
point  where  they  can  be  used  by  others  interested  in  experimenting  with  formal 
architecture  definition. 


7 


A  SRI’s  X/Open  DTP  Specification 
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%%%  starting  point  is  a  very  abstract  view  that  treats  the  collection  of 
%%%  resource  managers  as  a  single  component 

x_open_abstract_top :  ARCHITECTURE  [  ->  ] 

IMPORTING  ALL  FROM  Dataf low_Relations_style 

BEGIN 

CONFIGURATION 

%%  Note  that  the  following  aren't  really  component  declarations,  since 
%%  there  is  no  signature  declared.  We're  at  a  more  abstract  level,  where 
%%  all  we're  saying  is  that  there  are  components  called  the_ap,  et  al., 

%%  of  some  type  such  that  ...  . 

ap:  TYPE  <=  Function 

rms:  TYPE  <=  Function 
tm:  TYPE  <=  Function 

the_ap :  ap 
the_rms :  rms 
the_tm:  tm 

ar:  CONSTRAINT  =  Dataflow (the_ap,  the_rms) 

tx:  CONSTRAINT  =  Dataflow(the_ap,  the_tm) 

xa:  CONSTRAINT  =  Dataflow {the_tm,  the_rms) 


END  x_open_abstract_top 


%%%  First  step  is  to  go  to  a  style  that  makes  the  dataflow  connections 
%%%  explicit 

x_open_abstract_df :  ARCHITECTURE  [  ->  ] 

IMPORTING  ALL  FROM  Dataf low_style 
BEGIN 

ar_reguests :  TYPE 
ar_resources :  TYPE 
tx_commands ,  tx_responses :  TYPE 
xa_coinmands ,  xa_responses :  TYPE 

COMPONENTS 

ap:  TYPE  <=  Function  [ap_inl:  ar_resources ,  ap_in2 :  tx_responses 

->  ap_outl :  ar_requests,  ap_out2 :  tx_commands ] 

rms:  TYPE  <=  Function  [rm_inl:  ar_requests,  rm_in2 :  xa_commands 

->  rm_outl:  ar_re source s ,  rm_out2 ;  xa_responses] 

tm:  TYPE  <=  Function  [tm_inl:  tx_commands ,  tm_in2 :  xa_responses 

->  tm_outl:  tx_responses ,  tm_out2 :  xa_commands ] 

the_ap :  ap 
the_rms :  rms 
the_tm :  tm 

%%%  No  named  connectors,  due  to  parameterization,  hence  no  CONNECTORS  section 

CONFIGURATION 

ar_l:  CONNECTION  = 

(EXISTS  c:  Channel<ar_requests>) 

Connec  t  s ( c ,  the_ap . ap_out 1 ,  the_rms . rm_inl ) 
ar_2:  CONNECTION  = 

(EXISTS  c:  Channel<r_resources>) 

Connects ( c ,  the_rm. rm_outl ,  the_ap . ap_inl ) 

tx_l:  CONNECTION  = 

(EXISTS  c:  Channel<tx_commands>) 

Connects (c,  the_ap . ap_out2 ,  the_tm. tm_inl) 
tx_2:  CONNECTION  = 

(EXISTS  c:  Channel<tx_responses>) 

Connects (c,  the_tm. tm_outl ,  the_ap . ap_in2 ) 

xa_l:  CONNECTION  = 

(EXISTS  c:  Channel<xa_commands>) 

Connects ( c ,  the_tm . tm_out2 ,  the_rms . rm_in2 ) 
xa_2:  CONNECTION  = 

(EXISTS  c:  Channel<xa_responses>) 

Connects ( c ,  the_rms . rm_out2 ,  the_tm . tm_in2 ) 

END  x_open_abstract_df 
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%%%  Replace  the  aggregate  resource  managers  component  with  a 

%%%  ARCHITECTURE  that  contains  the  individual  resource  managers.  Although  this 
%%%  is  complicated,  it  seems  to  be  just  two  xformations,  one  applied  twice. 

%%%  First,  the  ports  and  channels  are  split.  Second,  the  Function  is 

%%%  replaced  by  a  ARCHITECTURE.  I  suppose  an  "empty"  ARCHITECTURE  could  be  introduced 

%%%  and  then  refined  by  adding  the  processes  —  which  has  to  be  done  all 

%%%  at  once  when  there  is  no  particular  number  of  them  which  is  what 

%%%  the  rule  in  the  paper  suggests,  but  that  just  complicates  analysis  of 

%%%  ARCHITECTURE  interface  constraints. 

%%%  After  the  two  channel  splitting,  we  have 
x_open_intermediate_l_df :  ARCHITECTURE  [  ->  ] 

IMPORTING  ALL  FROM  Dataf low_style 

BEGIN 

n:  NAT  %  Number  of  resource  managers,  a  parameter  in  the  specification 

ar_requests,  ar_resources :  TYPE 
tx_commands ,  tx_responses :  TYPE 
xa_commands ,  xa_responses :  TYPE 

%%  q_type(i)  will  be  the  subtype  of  ar_requests  accepted  by  the  i-th  resource 
%%  manager,  and  similarly  for  r_type(i)  and  ar_resources . 
q_type:  {i:  NAT  |  i  <  n}  — >  {t:  TYPE  |  t  <  ar_requests} 
r_type:  {i:  NAT  j  i  <  n}  — >  {t;  TYPE  j  t  <  ar_resources} 

COMPONENTS 

ap:  TYPE  <=  Function  [  «  ap_inl(i):  r_type(i)  |{i:  NAT)  i  <  n  », 

ap_in2 :  tx_responses 

->  «  ap_outl(i):  q_type(i)  |(i:  NAT)  i  <  n  », 
ap_out2 :  tx_commands] 

rms:  TYPE  <=  Function  [«  rm_inl(i):  q_type(i)  |(i:  NAT)  i  <  n  », 

«  rm_in2(i):  xa_commands  |  (i:  NAT)  i  <  n  » 

->  «  rm_outl(i);  r_type(i)  |(i:  NAT)  i  <  n  », 

«  rm_out2(i);  xa_responses  |  (i:  NAT)  i  <  n  »] 

tm:  TYPE  <=  Function  [tm_inl:  tx_commands, 

«  tm_in2(i):  xa_responses  |  (i:  NAT)  i  <  n  » 

->  tm_outl:  tx_responses , 

«  tm_out2(i):  xa_commands  |  (i:  NAT)  i  <  n  »] 

the_ap :  ap 
the_rms :  rms 
the_tm :  tm 

CONFIGURATION 

ar_l:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<q_type (i) >) 

Connects ( c ,  the_ap . ap_outl { i ) ,  the_rms . rm_inl { i ) ) 
ar_2:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<r_type (i) >) 

Connects ( c ,  the_rms . rm_outl ( i ) ,  the_ap . ap_inl ( i ) ) 

tx_l:  CONNECTION  = 

(EXISTS  c:  Channel<tx_commands>) 

Connects ( c ,  the_ap . ap_out2 ,  the_tm . tm_inl ) 
tx_2:  CONNECTION  = 
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xa_l 


xa_2 


END  X. 


(EXISTS  c:  Channel<tx_responses>) 

Connects  { c ,  the_tin .  tm_outl ,  the_ap .  ap_in2 ) 

CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<xa_coiranands>) 

Connects  ( c ,  the_tin .  tm_out2  ( i )  ,  the_rms .  rm_in2  ( i )  ) 
CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<xa_responses>) 

Connects  ( c ,  the_rms .  nn_out2  ( i )  /  the_tm .  titi_in2  ( i )  ) 

)en_intermediate_l_df 
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%%%  Refining  the  Function  the_nns  into  a  ARCHITECTURE  containing  many  rm's  yields 
x_open_intermediate_2_df :  ARCHITECTURE  [  ->  ] 

IMPORTING  ALL  FROM  Dataf low_style 

BEGIN 

n:  NAT  %  Niomber  of  resource  managers,  a  parameter  in  the  specification 

ar_requests ,  ar_resources :  TYPE 
tx_commands ,  tx_responses :  TYPE 
xa_commands ,  xa_responses :  TYPE 

%%  That  the  q_type  is  a  partition  of  ar_requests  is  guaranteed  by  the 
%%  general  constraints  on  ARCHITECTURE  interfaces  and  the  "completeness 
%%  assumption" .  (We  say  nothing  about  the  ports  of  the  resource 
%%  managers  —  in  particular,  we  mention  no  connections  wi thing  the 
%%  ARCHITECTURE  —  so  all  are  externally  visible.)  Ditto  for  r_type  and 
%%  ar_resources . 

q_type:  {i:  NAT  |  i  <  n}  — >  {t:  TYPE  |  t  <  ar_requests} 
r_type:  {i:  NAT  j  i  <  n)  — >  {t:  TYPE  j  t  <  ar_resources} 

COMPONENTS 

ap:  TYPE  <=  Fiinction  [«  ap_inl(i)  :  r_type(i)  |  (i:  NAT)  i  <  n  », 

ap_in2 :  tx_responses 

->  «  ap_outl(i):  q_type{i)  |  (i:  NAT)  i  <  n  », 
ap_out2 :  tx_commands ] 

rm:  TYPE  <=  {  p:  Function [rm_inl :  qt,  rm_in2 :  xa_commands 

->  rm_outl:  rt,  rm_out2 :  xa_responses] 

I  qt  <  ar_requests  AND  rt  <  ar_resources  } 

rms:  TYPE  <=  ARCHITECTURE  [«  rm_inl(i):  q_type(i)  |(i:  NAT)  i  <  n  », 

«  rm_in2(i):  xa_commands  |  (i:  NAT)  i  <  n  » 

->  «  rm_outl{i):  r_type(i)  |(i:  NAT)  i  <  n  », 

«  rm_out2(i):  xa_responses  |  (i:  NAT)  i  <  n  »] 

tm:  TYPE  <=  Function  [tm_inl:  tx_commands, 

«  tm_in2{i);  xa_responses  |  (i:  NAT)  i  <  n  » 

->  tm_outl:  tx_responses, 

«  tm_out2(i):  xa_coinmands  |  (i:  NAT)  i  <  n  »] 

the_ap :  ap 

the_rms :  rms 
the_tm :  tm 

CONFIGURATION 

rms_contents :  CONSTRAINT  = 

(FORALL  y:  COMPONENT) 

[y  PROPERLY_CONTAINED_IN  the_rms  =>  (EXISTS  z:  rm)  y  CONTAINED_IN  z] 
rm_location:  CONSTRAINT  = 

(FORALL  y:  rm)  [y  CONTAINED_IN  the_rms] 

ar_l:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<q_type (i) >) 

Connects ( c ,  the_ap . ap_outl ( i ) ,  the_rms . rm_inl ( i ) ) 
ar_2:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<r_type (i) >) 

Connects ( c ,  the_rms . rm_outl ( i ) ,  the_ap . ap_inl ( i ) ) 
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tx_l 

tx_2 

xa_l 

xa_2 

END  x_ 


CONNECTION  = 

(EXISTS  c:  Channel<tx_coinmands>) 

Connects  ( c ,  the_ap .  ap_out2 ,  the_tin .  tm_inl ) 
CONNECTION  = 

(EXISTS  c:  Channel<tx_responses>) 

Connects  (c,  the_tin.  tin_outl ,  the_ap . ap_in2 ) 

CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

( EXISTS  c :  Channel<xa_coinmands> ) 

Connects ( c ,  the_tm . tm_out2 ( i ) ,  the_rms .  nn_in2 ( i ) ) 
CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<xa_responses>) 

Connects  ( c ,  the_rms .  rm_out2  ( i )  ,  the_tm .  titi_in2  ( i )  ) 

>en_intermediate_2_df 
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%%%  Refine  the  TX  interface  by  splitting  the  tx_conimand, 

%%%  tx_response,  xa_coitimand,  and  xa_response  channels  to  set  up  use 
%%%  of  the  "actual"  commands  . 


x_open_concrete_df :  ARCHITECTURE  [  ->  ] 
IMPORTING  ALL  FROM  Dataf low_style 
BEGIN 


n:  NAT  %  Number  of  resource  managers,  a  parameter  in  the  specification 
ar_reguests,  ar_resources :  TYPE 

%%  Arguably,  the  whole  TX  interface  is  control  flow,  but  we'll  treat 
%%  the  integers  that  get  returned  as  data  to  stay  closer  to  the 
%%  actual  signatures 

tx_begin_response,  %  Note  that  there  is  no  dataflow  from  the  AP 

tx_close_response,  %  to  the  TM  on  many  commands,  so  there  is  no 

tx_commit_response,  %  need  for  a  command  type  decl'n 
tx_information_command,  tx_information_response, 
tx_open_response , 
tx_rollback_response :  TYPE 


ax_register_command,  ax_register_response , 

ax_unregister_command ,  ax_unregister_response , 
xa_close_command,  xa_close_response , 
xa_commit_command,  xa_commit_response , 
xa_complete_command,  xa_complete_response , 
xa_end_command,  xa_end_response, 
xa_f orget_command,  xa_f orget_response , 
xa_open_command ,  xa_open_response , 
xa _prepare_command ,  xa_prepare_response , 
xa_recover_command ,  xa_recover_response , 
xa_rollback_command,  xa_rollback_response , 
xa_start_command,  xa_start_response :  TYPE 


q_type:  {i:  NAT  |  i  <  n}  — >  {t:  TYPE  |  t  <  ar_requests} 
r_type:  {i:  NAT  j  i  <  n}  — >  {t:  TYPE  (  t  <  ar_resources} 


COMPONENTS 

ap:  TYPE  <=  Function  [«  ap_inl(i):  r_type(i)  |(i:  NAT)  i  <  n  », 

ap_begin_response_in :  tx_begin_response , 
ap_close_response_in :  tx_close_response , 
ap_commit_response_in :  tx_commit_response , 
ap_inf ormation_response_in :  tx_inf ormation_response , 
ap_open_response_in :  tx_open_response , 
ap_rollback_response_in :  tx_rollback_response 
->  «  ap_outl{i):  q_type(i)  |{i:  NAT)  i  <  n  », 

ap_inf ormation_command_out :  tx_inf ormation_command] 


rm:  TYPE  <=  {  p:  Function [rm_inl :  qt, 

rm_register_in:  ax_register_response, 
rm_unregister_in :  ax_unregister_response , 
rm_close_in:  xa_close_command, 
rm_commit_in:  xa_commit_command, 
rm_complete_in :  xa_complete_command, 
rm_end_in :  xa_end_command , 
rm_forget_in:  xa_forget_command, 
rm_open_in:  xa_open_command, 
rm_prepare_in :  xa_prepare_command , 
rm_recover_in :  xa_recover_command , 
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nn_rol lback_in :  xa_rol lback_coiranand , 
rm_start_in:  xa_start_coiTimand 
->  rm_outl:  rt, 

nn_register_out :  ax_register_coinmand, 
nn_unregi  ster_out :  ax_unregi  s  ter_coinmand , 
rm_close_out:  xa_close_response, 
nti_conimit_out:  xa_con\mit_response, 
nn_complete_out ;  xa_complete_response, 
nn_end_out:  xa_end_response, 
rm_f orget_out :  xa_f orget_response , 
rm_open_out :  xa_open_r e spons e , 
nxi_prepare_out :  xa_prepare_response , 
nn_recover_out :  xa_recover_response , 
nn_rol lback_out :  xa_rol lback_response , 
nn_start_out :  xa_start_response] 

I  qt  <  ar_requests  AND  rt  <  ar_resources  } 

rms:  TYPE  <=  ARCHITECTURE  [«  nn_inl(i):  q_type(i)  |(i:  NAT)  i  <  n  », 

«  nn_register_in(i) :  ax_register_response 
I (i :  NAT)  i  <  n  >>, 

«  rni_unregister_in(i)  :  ax_unregister_response 
I  (i :  NAT)  i  <  n  », 

«  rm_ciose_in(i)  :  xa_close_coinmand 
I  (i :  NAT)  i  <  n  », 

«  nn_cominit_in(i)  :  xa_coininit_conimand 
I  (i :  NAT)  i  <  n  », 

«  nn_complete_in(i) :  xa_complete_command 
I  (i;  NAT)  i  <  n  », 

«  nn_end_in{i) :  xa_end_command 
I  (i;  NAT)  i  <  n  », 

«  nti_forget_in{i)  :  xa_forget_coitffnand 
I  (i :  NAT)  i  <  n  », 

«  nti_open_in  { i )  :  xa_open_coni)nnand 
I  (i :  NAT)  i  <  n  », 

«  rm_prepare_in  ( i )  :  xa_prepare_cominand 
I  (i :  NAT)  i  <  n  », 

«  rm_recover_in ( i ) :  xa_recover_command 
I  (i :  NAT)  i  <  n  », 

«  nn_rollback_in(i)  :  xa_rollback_coinmand 
I  (i :  NAT)  i  <  n  », 

«  rrti_start_in(i)  :  xa_start_coinmand 
I (i:  NAT)  i  <  n  » 

->  «  nn_outl(i):  r_type{i)  |  (i:  NAT)  i  <  n  », 

<<  nn_register_out (i)  :  ax_register_coinmand 
I  (i :  NAT)  i  <  n  », 

«  rm_unregister_out{i) :  ax_unregister_command 
I  (i ;  NAT)  i  <  n  », 

«  nn_close_out (i) :  xa_close_response 
I  (i :  NAT)  i  <  n  », 

«  rm_cornmit_out  (i)  :  xa_cominit_response 
I  (i :  NAT)  i  <  n  », 

«  nti_complete_out  (i)  :  xa_convplete_response 
I  (i ;  NAT)  i  <  n  », 

«  nn_end_out { i ) :  xa_end_response 
I  (i:  NAT)  i  <  n  », 

«  nn_forget_out (i) ;  xa_forget_response 
I  (i :  NAT)  i  <  n  », 

«  rm_open_out { i ) :  xa_open_response 
I  (i :  NAT)  i  <  n  », 

«  nn_prepare_out ( i ) :  xa_prepare_response 
I  (i :  NAT)  i  <  n  », 

«  nn_recover_out (i) :  xa_recover_response 
I  (i :  NAT)  i  <  n  », 

«  nn_rollback_out(i) :  xa_rollback_response 
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I  (i;  NAT)  i  <  n  », 

«  rm_start_out ( i ) :  xa_start_response 
I  (i :  NAT)  i  <  n  »] 

tm:  TYPE  <=  Function  [tm_information_conimand_in;  tx_information_coinmand, 

«  tm_register_in(i) :  ax_register_coiranand 
I  (i:  NAT)  i  <  n  », 

«  tm_unregister_in ( i ) :  ax_unregister_coinmand 
I  (i:  NAT)  i  <  n  », 

«  tm_ciose_in(i) :  xa_close_response 
I  (i:  NAT)  i  <  n  », 

«  tin_commit_in(i)  :  xa_conimit_response 
I  (i:  NAT)  i  <  n  », 

«  tin_coinplete_in(i)  :  xa_complete_response 
I  (i:  NAT)  i  <  n  », 

«  tin_end_in  ( i )  :  xa_end_response 
I  (i:  NAT)  i  <  n  », 

«  tm_f orget_in { i ) :  xa_forget_response 
I  (i:  NAT)  i  <  n  », 

«  tm_open_in ( i ) :  xa_open_response 
I  (i:  NAT)  i  <  n  », 

«  tin_prepare_in  ( i )  :  xa_prepare_response 
I  (i:  NAT)  i  <  n  », 

«  tm_recover_in ( i ) :  xa_recover_response 
I  (i:  NAT)  i  <  n  », 

«  tm_rollbaclc_in(i)  :  xa_rollback_response 
I  (i:  NAT)  i  <  n  », 

«  tm_start_in(i) :  xa_start_response 
I (i:  NAT)  i  <  n  » 

->  tm_begin_response_out :  tx_begin_response, 

tm_close_response_out :  tx_close_response , 
tin_coinmit_response_out :  tx_coiiimit_response, 
tin_inf onnation_response_out :  tx_inf onnation_response , 
tin_open_response_out :  tx_open_response , 
tin_rollback_response_out :  tx_rollback_response , 

«  tm_register_out (i) :  ax_register_response 
I  (i:  NAT)  i  <  n  », 

«  tin_unregister_out  ( i )  :  ax_unregister_response 
I  (i:  NAT)  i  <  n  », 

<<  tm_close_out  (i)  :  xa_close_coinmand 
I  (i:  NAT)  i  <  n  », 

<<  tm_cominit_out (i)  :  xa_coinmit_coinmand 
I  (i:  NAT)  i  <  n  », 

«  tm_complete_out  ( i )  :  xa_complete_coinmand 
I  (i:  NAT)  i  <  n  », 

«  tm_end_out  ( i )  :  xa_end_coinmand 
I  (i:  NAT)  i  <  n  », 

«  tm_f orget_out ( i ) :  xa_f orget_command 
I  (i:  NAT)  i  <  n», 

<<  tm_open_out  ( i )  :  xa_open_coinmand 
I  (i :  NAT)  i  <  n  », 

«  tin_prepare_out  { i )  :  xa_prepare_coitimand 
I  (i :  NAT)  i  <  n  », 

«  tin_recover_out  { i )  :  xa_recover_conimand 
I  (i :  NAT)  i  <  n  », 

<<  tni_rollback_out  ( i )  :  xa_rollback_cdinmand 
I  (i:  NAT)  i  <  n», 

«  tin_start_out (i)  :  xa_start_coinmand 
I  (i :  NAT)  i  <  n  »] 

the_ap :  ap 
the_rms :  rms 
the_tm:  tm 
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CONFIGURATION 


nns_contents :  CONSTRAINT  = 

(FORALL  y:  COMPONENT) 

[y  PROPERLY_CONTAINED_IN  the_rms  =>  (EXISTS  z:  rm)  y  CONTAINED  IN  z] 
nn_location:  CONSTRAINT  =  “ 

(FORALL  y:  rm)  y  CONTAINED_IN  the_rms 

ar_l:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<q_type ( i ) > ) 

Connects  ( c ,  the_ap .  ap_outl  ( i ) ,  t]ie_rms .  rm_inl  ( i ) ) 
ar_2:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<r_type (i ) >) 

Connects ( c ,  the_rms . rm_outl ( i ) ,  the_ap . ap_inl ( i ) ) 

tx_l:  CONNECTION  = 

(EXISTS  c:  Channel<tx_information_coinmand>) 

Connects ( c ,  the_ap . ap_inf ormation_command_out , 
the_tm . tm_inf ormation_command_in ) 

tx_2a:  CONNECTION  = 

(EXISTS  c:  Channel<tx_begin_response>) 

Connects ( c ,  the_tm . tm_begin_response_out , 
tlie_ap .  ap_begin_response_in) 

tx_2b:  CONNECTION  = 

(EXISTS  c;  Channel<tx_close_response> ) 

Connects (c ,  the_tm. tm_close_response_out , 
the_ap . ap_close_response_in) 

tx_2c:  CONNECTION  = 

(EXISTS  c:  Channel<tx_commit_response> ) 

Connects ( c ,  the_tm . tm_commit_response_out , 
the_ap . ap_commit_response_in) 

tx_2d:  CONNECTION  = 

(EXISTS  c:  Channel<tx_information_response>) 

Connects (c,  the_tm. tm_infojnnation_response_out, 
the_ap . ap_information_response_in) 

tx_2e:  CONNECTION  = 

(EXISTS  c:  Channel<tx_open_response>) 

Connects ( c ,  the_tm . tm_open_response_out , 
the_ap . ap_open_response_in) 

tx_2f:  CONNECTION  = 

(EXISTS  c:  Channel<tx_rollback_response> ) 

Connects (c,  the_tm. tm_rollback_response_out, 
the_ap . ap_rollback_response_in) 


xa_la:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<ax_register_response>) 

Connects ( c ,  the_tra . tra_register_response_out ( i ) , 
the_rms . rm_register_response_in ( i ) ) 

xa_lb:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<ax_unregister_response>) 

Connects ( c ,  the_tm . tm_unregister_response_out ( i ) , 
the_rms . rm_unregister_response_in ( i ) ) 

xa_lc:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<xa_close_coinmand> ) 

Connects  ( c ,  the_tm .  tm_close_coinmand_out  ( i )  , 
the_rms .  rm_close_coinmand_in  ( i )  ) 

xa_ld:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<xa_commit_command>) 
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Connects  ( c ,  the_tin .  tm_coiranit_conimand_out  ( i )  , 
the_rms .  nn_coinmit_coinmand_in  { i ) ) 

xa_le:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<xa_complete_coiiimand>) 

Connects  ( c ,  the_tm .  tin_complete_command_out  { i )  , 
the_rms .  rm_complete_coinmand_in  ( i )  ) 

xa_lf:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<xa_end_coinmand>) 

Connects  ( c ,  the_tin .  titi_end_command_out  ( i )  , 
the_nns .  nn_end_command_in  ( i )  ) 

xa_lg:  CONNECTION  = 

(FORALL  i:  NAT  ]  i  <  n) 

(EXISTS  c:  Channel<xa_forget_coinmand>) 

Connects ( c ,  the_tm . tm_f orget_coiranand_out ( i ) , 
the_rms .  nn_f orget_coramand_in ( i ) ) 

xa_lh:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<xa_open_coinmand>) 

Connects  ( c ,  the_tm .  tm_open_coininand_out  ( i )  , 
the_nns .  nn_open_coinmand_in  ( i )  ) 

xa_li:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<xa_prepare_coinmand> ) 

Connects  ( c ,  the_tm .  tm_prepare_coinmand_out  ( i )  , 
the_nns .  nn_prepare_command_in  ( i )  ) 

xa_l j :  CONNECTION  = 

(FORALL  i:  NAT  j  i  <  n) 

(EXISTS  c:  Channel<xa_recover_coTnmand> ) 

Connects  ( c ,  the_tin .  titL.recover_coiTimand_out  ( i )  , 
the_nns .  nn_recover_coinmand_in  ( i )  ) 

xa_lk:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<xa_rollback_command>) 

Connects  ( c ,  the_tin .  tm_rollback_coininand_out  ( i )  , 
the_nns .  nn_rollback_coramand_in  ( i )  ) 

xa_ll:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<xa_start_coinmand>) 

Connects  ( c ,  the_tin .  tm_start_coinmand_out  ( i )  , 
the_nns .  nn_start_coinmand_in  ( i ) ) 

xa_2a:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<ax_register_command>) 

Connects  ( c ,  the_rms .  nn_register_coinmand_out  ( i )  , 
the_tin .  tin_register_coinmand_in  ( i ) ) 

xa_2b:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c;  Channel<ax_unregister_coinmand>) 

Connects  ( c ,  the_rms .  nn_unregister_comitiand_out  ( i )  , 
the_tm.  tin_unregister_coinmand_in ( i )  ) 

xa_2c:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<xa_close_response>) 

Connects ( c ,  the_rms . rm_close_response_out ( i ) , 
the_tin .  tm_close_response_in  ( i ) ) 

xa_2d:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<xa_commit_response>) 

Connects  ( c ,  the_nns .  rm_cominit_response_out  ( i )  , 
the_tm .  tm_coinmit_response_in  ( i )  ) 

xa_2e:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 
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(EXISTS  c:  Channel<xa_complete_response>) 

Connects ( c ,  the_rms .  nn_complete_response_out ( i ) , 
the_tm . tm_complete_response_in ( i ) ) 

xa_2f:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<xa_end_response>) 

Connects ( c ,  the_rms . rm_end_response_out ( i ) , 
the_tm . tm_end_response_in ( i ) ) 

xa_2g:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<xa_forget_response>) 

Connects ( c ,  the_nns . rm_f orget_response_out ( i ) , 
the_tin .  tin_f orget_response_in  ( i )  ) 

xa_2h:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<xa_open_response>) 

Connects ( c ,  the_rms . rra_open_response_out ( i ) , 
the_tm.  tin_open_response_in  ( i )  ) 

xa_2i:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<xa_prepare_response>) 

Connects ( c ,  the_rms .  nn_prepare_response_out ( i ) , 
the_tm. tm_prepare_response_in ( i ) ) 

xa_2 j :  CONNECTION  = 

(FORALL  i:  NAT  j  i  <  n) 

(EXISTS  c:  Channel<xa_recover_response>) 

Connects ( c ,  the_nns .  nn_recover_response_out ( i ) , 
the_tm . tm_recover_response_in ( i ) ) 

xa_2k:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<xa_rollback_response>) 

Connects ( c ,  the_rms . rm_rollback_response_out ( i ) , 
the_tm . tm_rollback_response_in ( i ) ) 

xa_21:  CONNECTION  = 

(FORALL  i:  NAT  ]  i  <  n) 

(EXISTS  c:  Channel<xa_start_response>) 

Connects ( c ,  the_nns . rm_start_response_out ( i ) , 
the_tm .  tin_start_response_in  ( i ) ) 

END  x_open_concrete_df 
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%%%  Introduce  the  actual  types  on  the  TX  and  XA  interfaces. 

%%%  Note  that  this  is  the  first  use  of  X/Open_style :  we  need  the  type 
%%%  definitions. 


x_open_truetypes_df :  ARCHITECTURE  [  ->  ] 

IMPORTING  ALL  FROM  Dataf low_style,  X_Open_style 
BEGIN 


n:  NAT  %  Number  of  resource  managers. 


parameter  in  the  specification 


ar_requests,  ar_resources :  TYPE 


q_type:  {i:  NAT  i  <  n} 
r_type:  {i:  NAT  i  <  n} 


{t:  TYPE  I  t  <  ar_requests} 
{t:  TYPE  I  t  <  ar_resources} 


COMPONENTS 

ap:  TYPE  <=  Function  [«  ap_inl(i):  r_type(i)  |(i:  NAT)  i  <  n  », 

ap_begin_response_in :  INT , 
ap_close_response_in:  INT, 
ap_commit_response_in:  INT, 
ap_inf ormation_response_in :  INT , 
ap_open_response_in :  INT , 
ap_rollback_response_in:  INT 
->  «  ap_outl(i):  ca_type{i)  |(i:  NAT)  i  <  n  », 
ap_information_command_out :  TX_Info] 


rm:  TYPE  <=  {  p:  Function [rm_inl :  qt, 

rm_register_in:  INT, 
rm_unregister_in:  INT, 
rm_close_in:  XA_Info  X  INT^2, 
rm_commit_in:  X_Id  X  INT^2, 
rm_complete_in:  INT^4, 
rm_end_in:  X_id  X  INT'' 2, 
rm_forget_in:  X_Id  X  INT''2, 
rm_open_in:  XA_Info  X  INT''2, 
rm_prepare_in :  X_Id  X  INT'' 2, 
rm_recover_in :  X_Ids  X  INT^3, 
rm_rollback_in:  X_Id  X  INT^2, 
rm_start_in:  X_Id  X  INT''2 
->  rm_outl:  rt, 

rm_register_out :  X_Id  X  INT''2, 
rm_unregister_out :  INT''2, 
rm_close_out :  INT, 
rm_coramit_out :  INT , 
rm_complete_out :  INT, 
rm_end_out :  INT , 
rm_f orget_out ;  INT , 
rm_open_out:  INT, 
rm_prepare_out :  INT , 
rm_recover_out ;  INT , 
rm_rol lback_out :  INT , 
rm_start_out :  INT] 

I  qt  <  ar_requests  AND  rt  <  ar_resources  } 

rms:  TYPE  <=  ARCHITECTURE  [«  rm_inl(i):  q_type(i)  |(i:  NAT)  i  <  n  », 

«  rm_register_in ( i ) :  INT 
I  (i:  NAT)  i  <  n  », 

«  rm_unregister_in(i) :  INT 
I  (i:  NAT)  i  <  n  », 

«  rm_close_in  ( i )  :  XA_Info  X  INT''2 
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I  (i:  NAT)  i  <  n  », 

«  nn_coinmit_in{i)  :  X_Id  X  INT^2 
I  (i :  NAT)  i  <  n  », 

«  nn_coinplete_in{i)  :  INT''4 
I  (i:  NAT)  i  <  n  », 

«  nn_end_in  ( i )  :  X_id  X  INT''2 
I  (i:  NAT)  i  <  n  », 

«  rm_f orget_in { i ) :  X_Id  X  INT^2 
I  (i :  NAT)  i  <  n  », 

«  nn_open_in  ( i )  :  XA_Info  X  INT''2 
I  (i:  NAT)  i  <  n  », 

«  rm_jprepare_in  { i )  :  X_Id  X  INT''2 
I  (i:  NAT)  i  <  n  », 

«  nii_recover_in  ( i )  :  X_Ids  X  INT^3 
I  (i :  NAT)  i  <  n  », 

«  rm_rollback_in(i) :  X_Id  X  INT^2 
I  (i :  NAT)  i  <  n  », 

«  nti_start_in  { i )  :  X_Id  X  INT''2 
I (i :  NAT)  i  <  n  » 

->  «  nn_outl(i):  r_type(i)  |(i:  NAT)  i  <  n  », 
«  rm_register_out (i)  :  X_Id  X  INT''2 
I  (i :  NAT)  i  <  n  », 

«  nn_unregister_out (i)  :  INT''2 
I  (i :  NAT)  i  <  n  », 

«  nn_ciose_out (i) :  INT 

I  (i :  NAT)  i  <  n  », 

«  nn_coinmit_out(i)  :  INT 
I  (i:  NAT)  i  <  n  », 

«  rm_complete_out (i) :  INT 
I  (i:  NAT)  i  <  n  », 

«  rm_end_out ( i ) :  INT 

I  (i:  NAT)  i  <  n  », 

«  rm^f orget_out ( i ) ;  INT 
I  (i:  NAT)  i  <  n  », 

«  nn_open_out ( i ) :  INT 

I  (i :  NAT)  i  <  n  », 

«  nn_prepare_out ( i ) :  INT 
I (i :  NAT)  i  <  n  >>, 

«  rm_recover_out ( i ) :  INT 
I  (i :  NAT)  i  <  n  », 

«  nn_rollback_out (i) :  INT 
I  (i:  NAT)  i  <  n  », 

«  rm_start_out (i) :  INT 

I  (i :  NAT)  i  <  n  »] 

tm:  TYPE  <=  Function  [tm_information_coinmand_in:  TX_Info, 

«  tm_register_in(i) :  X_Id  X  INT^2 
I { i :  NAT )  i  <  n  » , 

«  tin_unregister_in(i)  :  INT^2 
I  (i :  NAT)  i  <  n  », 

«  tin_ciose_in(i)  :  INT 

I  (i :  NAT)  i  <  n  », 

«  tm_coinmit_in(i)  :  INT 

I  (i :  NAT)  i  <  n  », 

«  tin_complete_in  ( i )  :  INT 
I ( i :  NAT )  i  <  n  » , 

«  tm_end_in(i) :  INT 

I  (i :  NAT)  i  <  n  », 

«  tm_f orget_in ( i ) :  INT 

I  (i :  NAT)  i  <  n  », 

«  tm_open_in ( i ) :  INT 

I  (i :  NAT)  i  <  n  », 
tm_prepare_in ( i ) :  INT 
I  (i :  NAT)  i  <  n  », 
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« 
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«  tm_recover_in { i ) :  INT 

1 (i:  NAT)  i  <  n  >>, 

«  tm_rollback_in(i) :  INT 
1  (i:  NAT)  i  <  n  », 

«  tm_start_in(i) :  INT 

I (i:  NAT)  i  <  n  » 

->  tin_begin_response_out :  INT , 

tm_close_response_out :  INT , 
tm_coinmit_response_out :  INT, 
titi_information_response_out :  INT, 
tin_open_response_out :  INT , 
tin_rollback_response_out :  INT , 

«  titi_register_out{i)  :  INT 
I  (i:  NAT)  i  <  n  », 

«  tm_unregister_out (i) :  INT 
I  (i:  NAT)  i  <  n  », 

<<  tni_close_out  ( i )  :  XA_Info  X  INT''2 
I  (i:  NAT)  i  <  n  », 

«  tm_coininit_out (i)  :  X_Id  X  INT''2 
I  (i:  NAT)  i  <  n  », 

«  tm_complete_out  ( i )  :  INT''4 
I  (i:  NAT)  i  <  n  », 

«  tm_end_out  ( i )  :  X_id  X  INT'' 2 
1  (i:  NAT)  i  <  n  », 

«  tin_forget_out  (i)  :  X_Id  X  INT^2 
I  (i:  NAT)  i  <  n  », 

<<  tm_open_out  ( i )  ;  XA_Info  X  INT''2 
I  (i:  NAT)  i  <  n  », 

«  tm_prepare_out  ( i )  :  X_Id  X  INT''2 
l  {i:  NAT)  i  <  n  », 

«  tin_recover_out  ( i )  :  X_Ids  X  INT''3 
I  (i:  NAT)  i  <  n  », 

«  tm_rollback_out (i)  :  X_Id  X  INT''2 
I  (i:  NAT)  i  <  n  », 

<<  tin_start_out (i)  :  X_Id  X  INT''2 
I  (i:  NAT)  i  <  n  »] 


the_ap :  ap 
the_rms :  rms 
the_tin :  tin 

CONFIGURATION 


nns_contents :  CONSTRAINT  - 

(FORALL  y:  COMPONENT) 

[y  PROPERLY_CONTAINED_IN  the_nns  => 
rm_location:  CONSTRAINT  = 

(FORALL  y:  rm)  y  CONTAINED_IN  the_nns 


(EXISTS  z:  rm)  y  CONTAINED_IN  z] 


ar_l:  CONNECTION  = 

(FORALL  i:  NAT  ]  i  <  n) 

(EXISTS  c:  Channel<q_type (i) >) 

Connects ( c ,  the_ap . ap_outl ( i ) ,  the_rms . rm_inl ( i ) ) 

ar_2:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<r_type(i)>) 

Connects ( c ,  the_rms . rm_outl ( i ) ,  the_ap . ap_inl ( i ) ) 


tx_l:  CONNECTION  = 

(EXISTS  c:  Channel<TX_Info>) 

Connects ( c ,  the_ap . ap_inf ormation_command_out , 
the_tm . tm_inf ormation_command_in ) 

tx_2a:  CONNECTION  = 

(EXISTS  c:  Channel<INT>) 
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tx_2b: 


tx_2c : 


tx_2d: 


tx_2e: 


tx_2  f : 


xa_la : 


xa_lb : 


xa_lc : 


xa_ld : 


xa_le : 


xa_lf : 


xa_lg : 


xa_lh : 


xa_li : 


Connects  ( c ,  the_tm .  tin_begin_response_out , 
the_ap . ap_begin_response_in) 

CONNECTION  = 

(EXISTS  c:  Channel<INT>) 

Connects (c,  the_tin. tm_close_response_out, 
the_ap . ap_close_response_in) 

CONNECTION  = 

(EXISTS  c:  Channel<INT>) 

Connects  ( c ,  the_tm .  tin_coinmit_response_out , 
the_ap .  ap_coinmit_response_in) 

CONNECTION  = 

(EXISTS  c:  Channel<INT>) 

Connects ( c ,  the_tin . tm_inf ormation_response_out , 
the_ap . ap_inf ormation_response_in) 

CONNECTION  = 

(EXISTS  c:  Channel<INT>) 

Connects  ( c ,  the_tm .  tin_open_response_out , 
the_ap . ap_open_response_in ) 

CONNECTION  = 

(EXISTS  c:  Channel<INT>) 

Connects ( c ,  the_tm . tm_rollback_response_out , 
the_ap . ap_rollback_response_in) 


CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c;  Channel<INT>) 

Connects  ( c ,  the_tm.  tin_register_response_out  ( i )  , 
the_rms . rm_register_response_in ( i ) ) 

CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<INT>) 

Connects  ( c ,  the_tin .  tin_unregister_response_out  ( i )  , 
the_inns .  nn_unregister_response_in ( i ) ) 

CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<XA_Info  X  INT''2>) 

Connects  ( c ,  the_tm .  tin_close_coinmand_out  ( i )  , 
the_rms .  nn_close_coiiimand_in  ( i ) ) 

CONNECTION  = 

(FORALL  i;  NAT  |  i  <  n) 

(EXISTS  c:  Channel<X_Id  X  INT^2>) 

Connects  ( c ,  the_tin .  tm_coininit_conimand_out  ( i )  , 
the_rms .  rm_coinmit_coinmand_in  ( i ) ) 

CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<INT^4>) 

Connects  ( c ,  the_tm .  tm_complete_coinmand_out  ( i )  , 
the_nns .  nn_complete_command_in  ( i ) ) 

CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<X_id  X  INT^2>) 

Connects ( c ,  the_tm . tm_end_coiranand_out ( i ) , 
the_rms . rm_end_command_in ( i ) ) 

CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<X_Id  X  INT^2>) 

Connects  ( c ,  the_tm .  tin_f orget_conimand_out  ( i )  , 
the_nns .  nn_f  orget_command_in  ( i )  ) 

CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<XA_Info  X  INT^2>) 

Connects  ( c ,  the_tm .  tin_open_coiranand_out  ( i )  , 
the_rms .  rm_open_coinmand_in  ( i ) ) 

CONNECTION  = 
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(FORALL  i:  NAT  |  i  <  n) 

{EXISTS  c:  Channel<X_Id  X  INT''2>) 

Connects  ( c ,  the_tm .  tm_prepare_coinmand_out  ( i )  , 
the_rms . rm_prepare_command_in ( i ) ) 

xa_l 3 ;  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<X_Ids  X  INT^3>) 

Connects  ( c ,  the_tm .  titi_recover_command_out  { i )  , 
the_rms .  nn_recover_command_in ( i ) ) 

xa_lk:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<X_Id  X  INT^2>) 

Connects  ( c ,  the _ tin .  tin_3rollback _ coirmand — out  ( i )  / 

the_nns .  nn_rollback_coinmand_in  { i ) ) 

xa_ll:  CONNECTION  = 

(FORALL  i:  NAT  j  i  <  n) 

(EXISTS  c:  Channel<X_Id  X  INT''2>) 

Connects  ( c ,  the_tm .  tm_start_coinmand_out  { i )  , 
the_rms . rm_start_command_in ( i ) ) 

xa_2a:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<X_Id  X  INT''2>) 

Connects  ( c ,  the_nns .  nn_register_coinmand_out  ( i )  , 
the_tm.  tm_register_coinmand_in  { i )  ) 

xa_2b:  CONNECTION  = 

(FORALL  i;  NAT  j  i  <  n) 

(EXISTS  c:  Channel<INT''2>) 

Connects  ( c ,  the_nns .  nn_unregister_conimand_out  ( i )  , 
the_tin .  tin_unregister_coininand_in  ( i )  ) 

xa_2c:  CONNECTION  = 

(FORALL  i:  NAT  j  i  <  n) 

(EXISTS  c:  Channel<INT>) 

Connects ( c ,  the_nns .  nn_close_response_out ( i ) , 
the_tni . tm_close_response_in ( i ) ) 

xa_2d:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<INT>) 

Connects  ( c ,  the_nns .  nn_coinmit_response_out  ( i )  , 
the_tm .  tm_coinmit_response_in  { i )  ) 

xa_2e:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<INT>) 

Connects  ( c ,  the_rms .  nn_coinplete_response_out  ( i )  , 
the_tin .  tm_complete_response_in  ( i ) ) 

xa_2f:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<INT>) 

Connects ( c ,  the_rms .  nn_end_response_out ( i ) , 
the_tm . tm_end_response_in ( i ) ) 

xa_2g:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<INT>) 

Connects ( c ,  the_nns .  nn_f orget_response_out { i ) , 
the_tin.  tm_forget_response_in ( i )  ) 

xa_2h:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<INT>) 

Connects ( c ,  the_nns .  nn_open_response_out ( i ) , 
the_tin .  tm_open_response_in  { i ) ) 

xa_2i:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<INT>) 

Connects ( c ,  the_nns .  nn_prepare_response_out ( i ) , 
the_tm.  tin_prepare_response_in ( i )  ) 
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xa_2j :  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<INT>) 

Connects ( c ,  the_rms . rm_recover_response_out ( i ) , 
the_tin .  tm_recover_response_in  ( i ) ) 

xa_2k:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<INT>) 

Connects ( c ,  the_rms .  nn_rollback_response_out ( i ) , 
the_tm .  tin_rollback_response_in  ( i ) ) 

xa_21:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  c:  Channel<INT>) 

Connects ( c ,  the_nns .  nn_start_response_out ( i ) , 
the_tm. tm_start_response_in ( i ) ) 

END  x_open_truetypes_df 
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%%%  Replace  TX  and  XA  dataflow  by  procedure  calls,  using 

%%%  pre-defined  procedure  call  varieties.  This  requires  first  replacing 
%%%  Functions  by  ARCHITECTURES,  so  that  the  procedure  declarations  can  be  stuck 
%%%  in  the  right  places.  (AP  is  changed  to  a  ARCHITECTURE  for  uniformity,  and 
%%%  to  eliminate  the  dependence  on  dataflow  style.) 

x_open_semiproc :  ARCHITECTURE  [  ->  ] 

IMPORTING  ALL  FROM  Dataf low_style, 

X_Open_style  %  defines  XA_Close_Procedure,  ...,  TX_Begin_Procedure , 


BEGIN 

n:  NAT  %  Number  of  resource  managers,  a  parameter  in  the  specification 
ar_requests,  ar_resources :  TYPE 

q_type:  {i:  NAT  |  i  <  n}  -->  {t:  TYPE  |  t  <  ar_requests) 
r_type:  {i:  NAT  j  i  <  n}  — >  {t:  TYPE  j  t  <  ar_resources} 

COMPONENTS 

ap:  TYPE  <=  ARCHITECTURE  [«  ap_inl(i):  r_type{i)  |(i:  NAT)  i  <  n  » 

->  «  ap_outl(i):  q_type(i)  |(i:  NAT)  i  <  n  »] 

rm;  TYPE  <=  {  m:  ARCHITECTURE  [rm_inl:  qt  ->  rm_outl:  rt] 

EXPORTING  ALL 
BEGIN 

close:  XA_Close_Procedure 

[info:  XA_Info,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

commit:  XA_Commit_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

complete :  XA_Complete_Procedure 

[hndl:  INT,  retval:  INT, 

rmid:  INT,  flags:  INT 
->  ret:  INT] 
end :  XA_End_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

forget :  XA_Forget_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 
open :  XA_Open_Procedure 

[info:  XA_Info,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

prepare :  XA_Prepare_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

recover :  XA_Recover_Procedure 

[ids:  X_Ids,  count:  INT, 

rmid:  INT,  flags:  INT 
->  ret:  INT] 

rollback:  XA_Rollback_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

start :  XA_Start_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

END  m 

I  qt  <  ar_requests  AND  rt  <  ar_resources  } 
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rms:  TYPE  <=  ARCHITECTURE  [«  rm_inl(i):  q_type(i)  |(i:  NAT)  i  <  n  » 

->  «  rm_outl(i):  r_type(i)  l(i:  NAT)  i  <  n  »] 

tm:  TYPE  <=  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 

register:  AX_Register_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

unregister :  AX_Unregister_Procedure 
[rmid:  INT,  flags:  INT 
->  ret:  INT] 

begin:  TX_Begin_Procedure  [  ->  ret:  INT] 
close:  TX_Close_Procedure  [  ->  ret:  INT] 
commit:  TX_Commit_Procedure  [  ->  ret:  INT] 

information:  TX_Info_Procedure  [info:  TX_Info  ->  ret:  INT] 
open:  TX_Open_Procedure  [  ->  ret:  INT] 
rollback:  TX_Rollback_Procedure  [  ->  ret:  INT] 

END  tm 

the_ap :  ap 
the_rms :  rms 
the_tm:  tm 


CONFIGURATION 


rms_contents :  CONSTRAINT  - 

(FORALL  y:  COMPONENT) 

[y  PROPERLY_CONTAINED_IN  the_rms  => 

rm_location:  CONSTRAINT  = 

(FORALL  y:  rm)  y  CONTAINED_IN  the_rms 


(EXISTS  z:  rm)  y  CONTAINED_IN  z] 


ar_l:  CONNECTION  = 

(FORALL  i:  NAT  j  i  <  n) 

(EXISTS  c:  Channel<q_type(i)>) 

Connects ( c ,  the_ap . ap_outl ( i ) ,  the_rms . rm_inl ( i ) ) 

ar_2:  CONNECTION  = 

(FORALL  i:  NAT  |  i  <  n)  _ 

(EXISTS  c:  Channel<r_type(i)>) 

Connects ( c ,  the_rms . rm_outl ( i ) ,  the_ap . ap_inl ( i ) ) 

%%  For  now,  let's  make  these  a  bit  more  readable  by  (implicitly) 

%%  existentially  quantifying  the  call  sites  away.  (Of  course,  we'll 
%%  eventually  need  them  in  the  mapping,  but  mappings  can  be  hidden 
%%  behind  the  scenes  on  the  transformational  approach.) 


tx:  CONSTRAINT  = 

Cal led_From ( the_tm . begin ,  the_ap ) 

AND  Called_From(the_tm. close,  the_ap) 

AND  Called_From(the_tm. commit,  the_ap) 

AND  Called_From(the_tm. information,  the_ap) 
AND  Called_From(the_tm.open,  the_ap) 

AND  Called_From(the_tm. rollback,  the_ap) 

xa:  CONSTRAINT  = 

(FORALL  y:  rm) 

[Called_From(the_tm. register,  y) 

AND  Called_From(the_tm. unregister,  y) 
AND  Called_From(y .close,  the_tm) 

AND  Called_From(y. commit,  the_tm) 

AND  Called_From(y. complete,  the_tm) 

AND  Called_From(y .end,  the_tm) 

AND  Called_From(y. forget,  the_tm) 

AND  Called_From(y.open,  the_tm) 
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AND  Called_From(y .prepare,  the_tin) 
AND  Called_Froin(y. recover,  the_tm) 
AND  Called_Froin(y. rollback,  the_tm) 
AND  Called_From(y.  start,  the_tin)  ] 

END  x_open_seiniproc 


30 


%%%  Replace  AR  dataflow  by  a  remote  procedure  call.  Note  that  use  of 
%%%  Dataflow_style  has  been  completely  eliminated. 

X  open  proc  1 :  ARCHITECTURE  [  ->  ] 

IMPORTING  ALL  FROM  X_Open_style, 

RPC_style  %  Introduces  Remotely  Callable  Procedures, 

%  RPCs,  an  implementation  of  PROCEDURES 

BEGIN 

COMPONENTS 

ap:  TYPE  <=  ARCHITECTURE  [  ->  ] 

rm:  TYPE  <=  {  m:  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 

access_f unction:  RPC  [in:  qt  ->  out:  rt] 
close:  XA_Close_Procedure 

[info:  XA_Info,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

commit:  XA_Commit_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

complete :  XA_Complete_Procedure 

[hndl:  INT,  retval:  INT, 

rmid:  INT,  flags;  INT 
->  ret:  INT] 
end:  XA_End_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

forget :  XA_Forget_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 
open :  XA_Open_Procedure 

[info:  XA_Info,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

prepare :  XA_Prepare_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

recover :  XA_Recover_Procedure 

[ids:  X_Ids,  count:  INT, 

rmid:  INT,  flags:  INT 
->  ret:  INT] 

rollback:  XA_Rollback_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

start :  XA_Start_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

END  m 

I  qt  <  ar_requests  AND  rt  <  ar_resources  } 

rms:  TYPE  <=  ARCHITECTURE  [  ->  ] 

tm:  TYPE  <=  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 

register:  AX_Register_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

unregister :  AX_Unregister_Procedure 
[rmid:  INT,  flags:  INT 
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->  ret:  INT] 

begin:  TX_Begin_Procedure  [  ->  ret:  INT] 

close:  TX_Close_Procedure  [  ->  ret:  INT] 

commit:  TX_Commit_Procedure  [  ->  ret:  INT] 

information:  TX_Info_Procedure  [info:  TX_Info  ->  ret:  INT] 

open:  TX_Open_Procedure  [  ->  ret:  INT] 

rollback:  TX_Rollback_Procedure  [  ->  ret:  INT] 

END  tm 


the_ap :  ap 

the_rms :  rms 
the_tm:  tm 

CONFIGURATION 

rms_contents :  CONSTRAINT  = 

(FORALL  y:  COMPONENT) 

[y  PROPERLY_CONTAINED_IN  the_rms  =>  (EXISTS  z:  rm)  y  CONTAINED_IN  z] 
rm_location:  CONSTRAINT  = 

(FORALL  y:  rm)  y  CONTAINED_IN  the_rms 

ar:  CONSTRAINT  = 

(FORALL  y:  rm)  Called_From(y.access_function,  the_ap) 
tx:  CONSTRAINT  = 

Called_From ( the_tm. begin,  the_ap) 

AND  Called_From(the_tm. close,  the_ap) 

AND  Called_From(the_tm. commit,  the_ap) 

AND  Called_From(the_tm. information,  the_ap) 

AND  Called_From(the_tm.open,  the_ap) 

AND  Cal led_From(the_tm. rollback,  the_ap) 

xa:  CONSTRAINT  = 

(FORALL  y:  rm) 

tCalled_From(the_tm. register,  y) 

AND  Called_From(the_tm. unregister,  y) 

AND  Called_From(y. close,  the_tm) 

AND  Called_From(y. commit,  the_tm) 

AND  Called_From(y. complete,  the_tm) 

AND  Called_From(y.end,  the_tm) 

AND  Called_From(y. forget,  the_tm) 

AND  Called_From(y.open,  the_tm) 

AND  Called_From(y. prepare,  the_tm) 

AND  Called_From(y. recover ,  the_tm) 

AND  Called_From(y. rollback,  the_tm) 

AND  Called_From(y. start,  the_tm) ] 

END  x_open_proc_l 
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%%%  Replace  AR  dataflow  by  a  pair  of  remote  procedure  calls.  Synchronize, 

%%%  but  don't  block  waiting  for  slow  resource  managers. 

X  open  proc  2 :  ARCHITECTURE  [  ->  ] 

IMPORTING  ALL  FROM  X_Open_style, 

RPC_style  %  Introduces  Remotely  Callable  Procedures, 

%  RPCs,  an  implementation  of  PROCEDURES 

BEGIN 

n:  NAT  %  Number  of  resource  managers,  a  parameter  in  the  specification 
ar_requests,  ar_resources :  TYPE 
COMPONENTS 

ap:  TYPE  <=  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 

{  return_resource (i) :  RPC  [in:  r_type(i)  ->  ]  | (i:  NAT)  i  <  n  } 

END  ap 

rm:  TYPE  <=  {  m:  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 

request_resource :  RPC  [in:  qt  ->  ] 
close :  XA_Close_Procedure 

[info:  XA_Info,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

commit:  XA_Commit_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

complete :  XA_Complete_Procedure 

[hndl:  INT,  retval:  INT, 

rmid:  INT,  flags:  INT 
->  ret:  INT] 
end :  XA_End_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

forget :  XA_Forget_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 
open :  XA_Open_Procedure 

[info:  XA_Info,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

prepare :  XA_Prepare_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

recover :  XA_Recover_Procedure 

[ids:  X_Ids,  count:  INT, 

rmid:  INT,  flags:  INT 
->  ret:  INT] 

rollback:  XA_Rollback_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

start :  XA_Start_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

END  m 

I  qt  <  ar_requests  AND  rt  <  ar_resources  } 
rms:  TYPE  <=  ARCHITECTURE  [  ->  ] 
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tm:  TYPE  <=  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 

register:  AX_Register_Procedure 

[id:  X_Id,  rraid:  INT,  flags:  INT 
->  ret:  INT] 

unregister :  AX_Unregister_Procedure 
[rmid:  INT,  flags:  INT 
->  ret:  INT] 

begin:  TX_Begin_Procedure  [  ->  ret:  INT] 
close:  TX_Close_Procedure  [  ->  ret:  INT] 
commit:  TX_Commit_Procedure  [  ->  ret:  INT] 

information:  TX_Info_Procedure  [info:  TX_Info  ->  ret:  INT] 
open:  TX_Open_Procedure  [  ->  ret:  INT] 
rollback:  TX_Rollback_Procedure  [  ->  ret:  INT] 

END  tm 

the_ap :  ap 
the_rms :  rms 
the_tm :  tm 

CONFIGURATION 

rms_contents :  CONSTRAINT  = 

(FORALL  y:  COMPONENT) 

[y  PROPERLY_CONTAINED_IN  the_rms  =>  (EXISTS  z:  rm)  y  CONTAINED_IN  z] 
rm_location:  CONSTRAINT  = 

(FORALL  y:  rm)  y  CONTAINED_IN  the_rms 

ar_l:  CONSTRAINT  = 

(FORALL  y:  rm)  Called_From(y .request_resource,  the_ap) 

ar_2:  CONSTRAINT  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  y:  rm) 

Called_From(return_resource(i) ,  y) 
tx:  CONSTRAINT  = 

Called_From ( the_tm. begin,  the_ap) 

AND  Called_From(the_tm. close,  the_ap) 

AND  Called_From(the_tm. commit,  the_ap) 

AND  Called_From(the_tm. information,  the_ap) 

AND  Called_From(the_tm.open,  the_ap) 

AND  Called_From(the_tm. rollback,  the_ap) 

xa:  CONSTRAINT  = 

(FORALL  y:  rm) 

[Called_From(the_tm. register,  y) 

AND  Called_From(the_tm. unregister,  y) 

AND  Called_From(y. close,  the_tm) 

AND  Called_From(y. commit,  the_tm) 

AND  Called_From(y. complete,  the_tm) 

AND  Called_From(y .end,  the_tm) 

AND  Called_From(y. forget,  the_tm) 

AND  Called_From(y.open,  the_tm) 

AND  Called_From(y. prepare,  the_tm) 

AND  Called_From(y. recover,  the_tm) 

AND  Called_From(y. rollback,  the_tm) 

AND  Called_From(y. start,  the_tm) ] 

END  x_open_proc_2 
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%%%  Replace  AR  dataflow  by  a  monitor,  to  make  the  communication  asynchronous 

x_open_proc_3 :  ARCHITECTURE  [  ->  ] 

IMPORTING  ALL  FROM  X_Open_style, 

RPC_style 

BEGIN 

n:  NAT  %  Number  of  resource  managers,  a  parameter  in  the  specification 
ar_requests ,  ar_resources :  TYPE 

q_type:  {i:  NAT  j  i  <  n}  -->  {t:  TYPE  |  t  <  ar_requests} 
r_type:  {i:  NAT  |  i  <  n}  — >  {t:  TYPE  j  t  <  ar_resources} 

COMPONENTS 

ap:  TYPE  <=  ARCHITECTURE  [  ->  ] 

mon:  TYPE  <=  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 

{  put_requests (i) :  RPC  [in:  q_type(i)  ->  ]  |(i:  NAT)  i  <  n  } 

{  get_requests (i) :  RPC  [  ->  out:  q_type(i)]  | (i:  NAT)  i  <  n  } 

{  put_resources (i) :  RPC  [in:  r_type{i)  ->  ]  [(i:  NAT)  i  <  n  } 

{  get_resources (i) :  RPC  [  ->  out:  r_type(i)]  |{i:  NAT)  i  <  n  } 
END  mon 

rm:  TYPE  <=  {  m:  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 

close:  XA_Close_Procedure 

[info:  XA_Info,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

commit:  XA_Commit_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

complete:  XA_Complete_Procedure 

[hndl:  INT,  retval:  INT, 

rmid:  INT,  flags:  INT 
->  ret:  INT] 
end :  XA_End_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

forget:  XA_Forget_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 
open :  XA_Open_Procedure 

[info:  XA_Info,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

prepare :  XA_Prepare_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

recover :  XA_Recover_Procedure 

[ids:  X_Ids,  count:  INT, 

rmid:  INT,  flags:  INT 
->  ret:  INT] 

rollback:  XA_Rollback_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

start:  XA_Start_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INTI 
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END  in 

I  qt  <  ar_requests  AND  rt  <  ar_resources  } 

rms:  TYPE  <=  ARCHITECTURE  [  ->  ] 

tm:  TYPE  <=  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 

register:  AX_Register_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

xmregister :  AX_Unregister_Procedure 
[rmid:  INT,  flags:  INT 
->  ret:  INT] 

begin:  TX_Begin_Procedure  [  ->  ret:  INT] 
close:  TX_Close_Procedure  [  ->  ret:  INT] 
commit:  TX_Commit_Procedure  [  ->  ret:  INT] 

information:  TX_Info_Procedure  [info:  TX_Info  ->  ret:  INT] 
open:  TX_Open_Procedure  [  ->  ret:  INT] 
rollback:  TX_Rollback_Procedure  [  ->  ret:  INT] 

END  tm 

the_ap :  ap 
the_rms :  rms 
the_tm:  tm 

CONFIGURATION 

rms_contents :  CONSTRAINT  = 

(FORALL  y:  COMPONENT) 

[y  PROPERLY_CONTAINED_IN  the_rms  =>  (EXISTS  z:  rm)  y  CONTAINED_IN  z] 

rm_location:  CONSTRAINT  = 

(FORALL  y:  rm)  y  CONTAINED_IN  the_rms 

ar_l:  CONSTRAINT  = 

(FORALL  i:  NAT  |  i  <  n) 

[Called_From(put_requests ( i ) ,  the_ap) 

AND  Called_From(get_resources (i) ,  the_ap) ] 

ar_2:  CONSTRAINT  = 

(FORALL  i:  NAT  |  i  <  n) 

(EXISTS  y:  rm) 

[Called_From(put_resource(i) ,  y) 

AND  Called_From(get_requests (i) ,  y) ] 

tx:  CONSTRAINT  = 

Called_From ( the_tm . begin,  the_ap ) 

AND  Called_From(the_tm. close,  the_ap) 

AND  Called_From(the_tm. commit,  the_ap) 

AND  Called_From(the_tm. information,  the_ap) 

AND  Called_From(the_tm.open,  the_ap) 

AND  Called_From(the_tm. rollback,  the_ap) 

xa:  CONSTRAINT  = 

(FORALL  y:  rm) 

[Called_From(the_tm. register,  y) 

AND  Called_From(the_tm. unregister,  y) 

AND  Called_From(y. close,  the_tm) 

AND  Called_From(y. commit,  the_tm) 

AND  Called_From(y .complete,  the_tm) 

AND  Called_From(y.end,  the_tra) 

AND  Called_From(y. forget,  the_tm) 

AND  Called_From(y.open,  the_tm) 

AND  Called_From(y. prepare,  the_tm) 
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AND  Called_Froin(y. recover,  the_tin) 
AND  Called_Froin{y. rollback,  the_tin) 
AND  Called_From(y. start,  the_tm) ] 

END  x_open_proc_3 
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%%%  Pick  a  value  for  n,  as  a  first  step  toward  making  things  concrete 

x_open_instance :  ARCHITECTURE  [  ->  ] 

IMPORTING  ALL  FROM  X_Open_style, 

RPC_style 

BEGIN 

ar_requests,  ar_resources :  TYPE 
COMPONENTS 

ap:  TYPE  <=  ARCHITECTURE  [  ->  ] 

rm:  TYPE  <=  {  m:  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 

access_function:  RPC  [in:  qt  ->  out:  rt] 
close:  XA_Glose_Procedure 

[info:  XA_Info,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

commit :  XA_Commit_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

complete:  XA_Complete_Procedure 

[hndl:  INT,  retval:  INT, 

rmid:  INT,  flags:  INT 
->  ret:  INT] 
end:  XA_End_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

forget :  XA_Forget_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 
open :  XA_Open_Procedure 

[info:  XA_Info,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

prepare :  XA_Prepare_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

recover :  XA_Recover_Procedure 

[ids:  X_Ids,  count:  INT, 

rmid:  INT,  flags:  INT 
->  ret:  INT] 

rollback:  XA_Rollback_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

start:  XA_Start_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

END  m 

I  qt  <  ar_requests  AND  rt  <  ar_resources  } 

rms:  TYPE  <=  ARCHITECTURE  [  ->  ] 

tm:  TYPE  <=  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 

register:  AX_Register_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

unregister :  AX_Unregister_Procedure 
[rmid:  INT,  flags:  INT 
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->  ret:  INT] 

begin:  TX_Begin_Procedure  [  ->  ret:  INT] 

close:  TX_Close_Procedure  [  ->  ret:  INT] 

commit:  TX_Commit_Procedure  [  ->  ret:  INT] 

information:  TX_Info_Procedure  [info:  TX_Info  ->  ret:  INT] 

open:  TX_Open_Procedure  [  ->  ret:  INT] 

rollback:  TX_Rollback_Procedure  [  ->  ret:  INT] 

END  tm 


the_ap :  ap 
the_rms :  rms 
the_rm_l :  rm 
the_rm_2 :  rm 
the_tm:  tm 

CONFIGURATION 

rms_contents :  CONSTRAINT  = 

(FORALL  y:  COMPONENT) 

[y  PROPERLY_CONTAINED_IN  the_rms  => 

[y  CONTAINED_IN  the_rm_l  OR  y  CONTAINED_IN  the_rm_2 ] ] 
rm_location:  CONSTRAINT  = 

the_rm_l  CONTAINED_IN  the_rms  AND  the_rm_2  CONTAINED_IN  the_rms 
ar:  CONSTRAINT  = 

Called_From(the_rm_l .access_function,  the_ap) 

AND  Called_From(the_rm_2 .access_function,  the_ap) 

tx:  CONSTRAINT  = 

Cal led_From ( the_tm . begin ,  the_ap ) 

AND  Cal led_From(the_tm. close,  the_ap) 

AND  Cal led_From ( the_tm . commit ,  the_ap ) 

AND  Called_From(the_tm. information,  the_ap) 

AND  Called_From(the_tm.open,  the_ap) 

AND  Called_From(the_tm. rollback,  the_ap) 

xa:  CONSTRAINT  = 

Called_From(the_tm. register,  the_rm_l) 

AND  Called_From(the_tm. unregister,  the_rm_l) 

AND  Called_From(the_rm_l .close,  the_tm) 

AND  Called_From{the_rm_l .commit,  the_tm) 

AND  Cal led_From(the_rm_l .complete,  the_tm) 

AND  Called_From(the_rm_l .end,  the_tm) 

AND  Cal led_From ( the_rm_l . forget,  the_tm) 

AND  Called_From(the_rm_l .open,  the_tm) 

AND  Called_From{the_rm_l .prepare,  the_tm) 

AND  Called_From ( the_rm_l . recover,  the_tm) 

AND  Called_From(the_rm_l . rollback,  the_tm) 

AND  Call ed_Fr om ( the_rm_l .start,  the_tm ) 

AND  Called_From ( the_tm . register ,  the_rm_2 ) 

AND  Called_From(the_tm. unregister,  the_rm_2) 

AND  Called_From(the_rm_2 .close,  the_tm) 

AND  Called_From(the_rm_2 .commit,  the_tm) 

AND  Called_From(the_rm_2 .complete,  the_tm) 

AND  Called_From(the_rm_2 .end,  the_tm) 

AND  Called_From{the_rm_2 . forget,  the_tm) 

AND  Called_From(the_rm_2 . open,  the_tm) 

AND  Cal led_From(the_rm_2 .prepare,  the_tm) 

AND  Called_From{the_rm_2 .recover,  the_tm) 

AND  Called_From(the_rm_2 .rollback,  the_tm) 

AND  Called_From(the_rm_2 . start,  the_tm) 

END  x_open_instance 
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%%%  Break  up  AP  into  main  process  and  an  auxiliary  process  that  will  be 
%%%  co-located  with  the  TM  and  the  RMs.  Step  one  is  to  refine  example-6 
%%%  into  something  that  looks  like  example-7,  but  with  generic  procedure 
%%%  calls  in  place  of  the  RPCs.  (So  this  oculd  actually  be  above 
%%%  example-7  in  the  tree,  rather  than  a  separate  branch.) 

x_open_proc_4 :  ARCHITECTURE  [  ->  ] 

IMPORTING  ALL  FROM  X_Open_style 

BEGIN 

n:  NAT  %  Number  of  resource  managers,  a  parameter  in  the  specification 
ar_requests ,  ar_resources :  TYPE 
COMPONENTS 

ap:  TYPE  <=  ARCHITECTURE  [  ->  ] 

rm:  TYPE  <=  {  m:  ARCHITECTURE  [  ->  } 

EXPORTING  ALL 
BEGIN 

access_function:  PROCEDURE  [in:  qt  ->  out:  rt] 
close:  XA_Close_Procedure 

[info:  XA_Info,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

commit:  XA_Commit_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

complete :  XA_Complete_Procedure 

[hndl:  INT,  retval:  INT, 

rmid:  INT,  flags:  INT 
->  ret:  INT] 
end:  XA_End_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

forget :  XA_Forget_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 
open :  XA_Open_Procedure 

[info:  XA_Info,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

prepare :  XA_Prepare_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

recover:  XA_Recover_Procedure 

[ids:  X_Ids,  count:  INT, 

rmid:  INT,  flags:  INT 
->  ret:  INT] 

rollback:  XA_Rollback_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

start :  XA_Start_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

END  m 

I  qt  <  ar_requests  AND  rt  <  ar_resources  } 

rms:  TYPE  <=  ARCHITECTURE  [  ->  ] 

tm:  TYPE  <=  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 
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register:  AX_Register_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

unregister :  AX_Unregister_Procedure 
[rmid:  INT,  flags:  INT 
->  ret:  INT] 

begin:  TX_Begin_Procedure  [  ->  ret:  INT] 

close:  TX_Close_Procedure  [  ->  ret:  INT] 

commit:  TX_Commit_Procedure  [  ->  ret:  INT] 

information:  TX_Info_Procedure  [info:  TX_Info  ->  ret:  INT] 

open:  TX_Open_Procedure  [  ->  ret:  INT] 

rollback:  TX_Rollback_Procedure  [  ->  ret:  INT] 

END  tm 


the_ap :  ap 
the_rms :  rms 
the_tm:  tm 

CONFIGURATION 

rms_contents :  CONSTRAINT  = 

(FORALL  y:  COMPONENT) 

[y  PROPERLY_CONTAINED_IN  the_rms  =>  (EXISTS  z :  rm)  y  CONTAINED_IN  z] 
rm_location:  CONSTRAINT  = 

(FORALL  y:  rm)  y  CONTAINED_IN  the_rms 

ar:  CONSTRAINT  = 

(FORALL  y:  rm)  Called_From(y.access_function,  the_ap) 
tx:  CONSTRAINT  = 

Cal led_From ( the_tm . begin ,  the_ap ) 

AND  Called_From(the_tm. close,  the_ap) 

AND  Called_From(the_tm. commit,  the_ap) 

AND  Called_From(the_tm. information,  the_ap) 

AND  Called_From(the_tm. open,  the_ap) 

AND  Called_From(the_tm. rollback,  the_ap) 

xa:  CONSTRAINT  = 

(FORALL  y:  rm) 

[Called_From(the_tm. register,  y) 

AND  Called_From(the_tm. unregister,  y) 

AND  Called_From(y. close,  the_tm) 

AND  Called_From(y. commit,  the_tm) 

AND  Called_From(y. complete,  the_tm) 

AND  Called_From(y.end,  the_tm) 

AND  Called_From(y. forget,  the_tm) 

AND  Called_From(y.open,  the_tm) 

AND  Called_From(y .prepare,  the_tm) 

AND  Called_From(y. recover,  the_tm) 

AND  Called_From(y. rollback,  the_tm) 

AND  Called_From(y. start,  the_tm) ] 

END  x_open_proc_4 
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%%%  Break  up  AP  into  main  process  and  an  auxiliary  process  that  will  be 
%%%  co-located  with  the  TM  and  the  RMs.  This  is  an  intermediate  step  in 
%%%  which  the  various  boxes  representing  the  aiixiliary  interface  processes 
%%%  for  the  AP  and  the  TM  are  each  combined  into  a  single  box. 

x_open_ap_decomposition:  ARCHITECTURE  [  ->  ] 

IMPORTING  ALL  FROM  X_Open_style,  RPC_style 

BEGIN 

n:  NAT  %  Number  of  resource  managers,  a  parameter  in  the  specification 
ar_requests,  ar_resources :  TYPE 
resource_id:  TYPE  =  {  i:  NAT  |  i  <  n  } 

COMPONENTS 

%%  The  next  two  type  definitions  could  simply  be  declared  within  the  ap 
%%  declaration,  since  the  number  is  fixed,  but  might  as  well  do  it  like  rm. 

ap_main:  TYPE  <=  ARCHITECTURE  [  ->  ] 

ap_aiax:  TYPE  <=  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 

parameterized_access_function : 

RPC  [r_id:  resource_id,  in:  ar_requests  ->  out:  ar_resources] 
begin:  RPC  [  ->  ret:  INT] 
close:  RPC  [  ->  ret:  INT] 
commit:  RPC  [  ->  ret:  INT] 

information:  RPC  [info:  TX_Info  ->  ret:  INT] 
open:  RPC  [  ->  ret:  INT] 
rollback:  RPC  [  ->  ret:  INT] 

END  ap_aux 

ap:  TYPE  <=  ARCHITECTURE  [  ->  ] 

rm:  TYPE  <=  {  m:  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 

access_f unction:  PROCEDURE  [in:  qt  ->  out:  rt] 
close:  XA_Close_Procedure 

[info:  XA_Info,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

commit:  XA_Commit_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

complete :  XA_Complete_Procedure 

[hndl:  INT,  retval :  INT, 

rmid:  INT,  flags:  INT 
->  ret:  INT] 
end:  XA_End_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

forget :  XA_Forget_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 
open :  XA_Open_Procedure 

[info:  XA_Info,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

prepare :  XA_Prepare_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 

42 


->  ret:  INT] 

recover :  XA_Recover_Procedure 

[ids:  X_Ids,  count:  INT, 

rmid:  INT,  flags:  INT 
->  ret:  INT] 

rollback:  XA_Rollback_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
■  ->  ret:  INT] 
start:  XA_Start_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

END  m 

I  qt  <  ar_requests  AND  rt  <  ar_resources  } 

rms:  TYPE  <=  ARCHITECTURE  [  ->  ] 

tm_main:  TYPE  <=  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 

register:  RPC 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 
unregister :  RPC 

[rmid:  INT,  flags:  INT 
->  ret:  INT] 

begin:  TX_Begin_Procedure  [  ->  ret:  INT] 
close:  TX_Close_Procedure  [  ->  ret:  INT] 
commit:  TX_Commit_Procedure  [  ->  ret:  INT] 

information:  TX_Info_Procedure  [info:  TX_Info  ->  ret:  INT] 
open:  TX_Open_Procedure  [  ->  ret;  INT] 
rollback:  TX_Rollback_Procedure  [  ->  ret:  INT] 

END  tnumain 

tm_aux:  TYPE  <=  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 

register:  AX_Register_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

unregister :  AX_Unregister_Procedure 
[rmid:  INT,  flags:  INT 
->  ret:  INT] 

close:  RPC  [info:  XA_Info,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

commit:  RPC  ,  [id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

complete;  RPC  [hndl:  INT,  retval:  INT, 

rmid:  INT,  flags:  INT 
->  ret:  INT] 

end:  RPC  [id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

forget:  RPC  [id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

open:  RPC  [info:  XA_Info,  rmid;  INT,  flags:  INT 
->  ret:  INT] 

prepare:  RPC  [id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

recover :  RPC  [ ids :  X_Ids ,  count :  INT , 

rmid:  INT,  flags:  INT 
->  ret:  INT] 

rollback:  RPC  [id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

start:  RPC  [id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 
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END  tin_aiix 


tin:  TYPE  <=  ARCHITECTURE  [  ->  ] 

the_ap :  ap 
the_ap_inain :  ap_inain 
the_ap_aiax :  ap_aux 
the_nns :  rms 
the_tin:  tm 

the_tin_inain :  tin_main 

the_tin_aiix :  tm_aux 

CONFIGURATION 

ap_contents :  CONSTRAINT  = 

(FORALL  y:  COMPONENT) 

[y  PROPERL Y_CONTAINED_IN  the_ap 

=>  y  CONTAINED_IN  the_ap_main  OR  y  CONTAINED_IN  the_ap_aiix] 

ap_main_location:  CONSTRAINT  = 

the_ap_inain  CONTAINED_IN  the_ap 
ap_aux_location:  CONSTRAINT  = 

the_ap_aux  CONTAINED_IN  the_ap 

tin_contents :  CONSTRAINT  = 

(FORALL  y:  COMPONENT) 

[y  PROPERLY_CONTAINED_IN  the_tin 

=>  y  CONTAINED^IN  the_tm_inain  OR  y  CONTAINED_IN  the_tin_aux] 

tinjnain_location:  CONSTRAINT  = 

the_tin_main  CONTAINED_IN  the_tm 
tin_aux_location:  CONSTRAINT  = 

the_trcL.aux  CONTAINED_IN  the_tm 

nns_contents :  CONSTRAINT  = 

(FORALL  y:  COMPONENT) 

[y  PROPERL Y_CONTAINED_IN  the_rms  =>  (EXISTS  z:  rm)  y  CONTAINED_IN  z] 
nn_location:  CONSTRAINT  = 

(FORALL  y:  rm)  y  CONTAiNED_IN  the_rms 

ar:  CONSTRAINT  = 

(FORALL  y:  rm)  Called_From(y.access_function,  the_ap_aux) 
tx:  CONSTRAINT  = 

Cal led_From ( the_tm_main . begin ,  the_ap_aux) 

AND  Called_From(the_tm_main. close,  the_ap_aux) 

AND  Called_From(the_tm_main. commit,  the_ap_aux) 

AND  Called_From(the_tm_main. information,  the_ap_aux) 

AND  Cal led_From ( the_tm_main . open ,  the_ap_aux ) 

AND  Called_From(the_tm_main. rollback,  the_ap_aux) 

xa:  CONSTRAINT  = 

(FORALL  y:  rm) 

[Called_From ( the_tm_aux . register ,  y ) 

AND  Called_From(the_tm_aux. unregister,  y) 

AND  Called_From(y. close,  the_tm_aux) 

AND  Called_From(y. commit,  the_tm_aux) 

AND  Called_From(y. complete,  the_tm_aux) 

AND  Called_From(y.end,  the_tm_aux) 

AND  Called_From(y. forget,  the_tm_aux) 

AND  Called_From(y.open,  the_tm_aux) 

AND  Call ed_Fr om ( y . prepare ,  the_tm_aux ) 

AND  Called_From(y. recover,  the_tm_aux) 

AND  Called_From(y. rollback,  the_tm_aux) 

AND  Called_From(y. start,  the_tm_aux) ] 
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intra_ap :  CONSTRAINT  = 

Called_From(paraineterized_access_function. the_ap_aux,  the_ap) 
AND  Called_From(the_ap_aux. begin,  the_ap) 

AND  Cal led_Froin(the_ap_aux. close,  the_ap) 

AND  Cal led_From(the_ap_aux. commit,  the_ap) 

AND  Called_From(the_ap_aux. information,  the_ap) 

AND  Called_From(the_ap_aux.open,  the_ap) 

AND  Called_From(the_ap_aux. rollback,  the_ap) 

intra_tm:  CONSTRAINT  = 

Called_From ( the_tm_main . register,  the_tm_aux) 

AND  Called_From(the_tm_main. unregister,  the_tm_aux) 

AND  Called_From(the_tm_aux. close,  the_tm_main) 

AND  Called_From(the_tm_aux. commit,  the_tm_main) 

AND  Called_From(the_tm_aux. complete,  the_tm_main) 

AND  Called_From(the_tm_a\ix.end,  the_tm_main) 

AND  Cal led_From(the_tm_aux. forget,  the_tm_main) 

AND  Called_From(the_tm_aux.open,  the_tm_main) 

AND  Called_From(the_tm_aux. prepare,  the_tm_main) 

AND  Cal led_From(the_tm_aux. recover,  the_tm_main) 

AND  Called_From(the_tm_aux. rollback,  the_tm_main) 

AND  Called_From(the_tm_aux. start,  the_tm_main) 


END  x_open_ap_decomposition 
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%%%  Break  out  interfaces  of  ap_ar_aux  and  tin_aux  to  handle  distributed  RMs. 
x_open_ap_aux_decomposition:  ARCHITECTURE  [  ->  ] 

IMPORTING  ALL  FROM  X_Open_style,  RPC_style 
BEGIN 

n:  NAT  %  Number  of  resource  managers,  a  parameter  in  the  specification 
ar_requests ,  ar_resources :  TYPE 
COMPONENTS 

ap_main:  TYPE  <=  ARCHITECTURE  [  ->  ] 

ap_tx_avix:  TYPE  <=  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 

begin:  RPC  [  ->  ret:  INT] 
close:  RPC  [  ->  ret:  INT] 
commit:  RPC  [  ->  ret:  INT] 

information:  RPC  [info:  TX_Info  ->  ret:  INT] 
open:  RPC  [  ->  ret:  INT] 
rollback:  RPC  [  ->  ret:  INT] 

END  ap_tx_aux 

ap_ar_aux:  TYPE  <=  {m:  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 

access_function: 

RPC  [in:  qt  ->  out:  rt] 

END  m 

I  qt  < ■ar_requests  AND  rt  <  ar_resources  } 

ap:  TYPE  <=  ARCHITECTURE  [  ->  ] 

rm:  TYPE  <=  {  m:  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 

access_function:  PROCEDURE  [in:  qt  ->  out:  rt] 
close:  XA_Close_Procedure 

[info:  XA_Info,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

commit:  XA_Commit_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

complete :  XA_Complete_Procedure 

[hndl:  INT,  retval :  INT, 

rmid:  INT,  flags:  INT 
->  ret:  INT] 
end :  XA_End_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

forget :  XA_Forget_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 
open :  XA_Open_Procedure 

[info:  XA_Info,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

prepare :  XA_Prepare_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

recover :  XA_Recover_Procedure 
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[ids:  X_Ids,  count:  INT, 

ntiid:  INT,  flags:  INT 
->  ret:  INT] 

rollback:  XA_Rollback_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

start :  XA_Start_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

END  m 

I  qt  <  ar_requests  AND  rt  <  ar_resources  } 

rms:  TYPE  <=  ARCHITECTURE  [  ->  ] 

tm_main:  TYPE  <=  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 

register :  RPC 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 
unregister:  RPC 

[rmid:  INT,  flags:  INT 
->  ret:  INT] 

begin:  TX_Begin_Procedure  [  ->  ret:  INT] 

close:  TX_Close_Procedure  [  ->  ret:  INT] 

commit:  TX_Commit_Procedure  [  ->  ret:  INT] 

information:  TX_Info_Procedure  [info:  TX_Info  ->  ret:  INT] 

open:  TX_Open_Procedure  [  ->  ret:  INT] 

rollback:  TX_Rollback_Procedure  [  ->  ret:  INT] 

END  tm_main 

tnuaux;  TYPE  <=  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL. 

BEGIN 

register:  AX_Register_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

iinregister:  AX_Unregister_Procedure 
[rmid:  INT,  flags:  INT 
->  ret:  INT] 

close:  RPC  [info:  XA_Info,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

commit:  RPC  [id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

complete:  RPC  [hndl:  INT,  retval:  INT, 

rmid:  INT,  flags:  INT 
->  ret:  INT] 

end:  RPC  [id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

forget:  RPC  [id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

open:  RPC  [info:  XA_Info,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

prepare:  RPC  [id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

recover:  RPC  [ids:  X_Ids,  co\mt:  INT, 

rmid:  INT,  flags:  INT 
->  ret:  INT] 

rollback:  RPC  [id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

start:  RPC  [id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

END  tm_aux 
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tm:  TYPE  <=  ARCHITECTURE  [  ->  ] 


the_ap :  ap 

the_ap_main :  ap_main 
the_ap_tx_aux :  ap_tx_aux 
the_nns :  rms 
the_tni :  tm 

the_tm_main :  tm_main 

CONFIGURATION 

ap_contents:  CONSTRAINT  = 

(FORALL  y:  COMPONENT) 

[y  PROPERLY_CONTAINED_IN  the_ap 

=>  y  CONTAINED_IN  the_ap_main 

OR  y  CONTAINED_IN  the_ap_tx_aux 
OR  (EXISTS  w:  ap_ar_aux)  y  CONTAINED_IN  w] 
ap_main_location:  CONSTRAINT  = 

the_ap_main  CONTAINED_IN  the_ap 
tx_a\ix_location:  CONSTRAINT  = 

the_ap_aux  CONTAINED_IN  the_ap 
ra_atix_location:  CONSTRAINT  = 

(FORALL  w:  ap_ar_aiix)  w  CONTAINED_IN  the_ap 

tm_contents :  CONSTRAINT  = 

(FORALL  y:  COMPONENT) 

[y  PROPERL Y_CONTAINED_IN  the_tm 

=>  y  CONTAINED_IN  the_tm_main 

OR  (EXISTS  w:  tm_aux)  y  CONTAINED_IN  w] 
tm_main_location:  CONSTRAINT  = 

the_tm_main  CONTAINED_IN  the_tm 
tm_atix_location:  CONSTRAINT  = 

(FORALL  w:  tm_axax)  w  CONTAINED_IN  the_tm 

rms_contents ;  CONSTRAINT  = 

(FORALL  y:  COMPONENT) 

[y  PROPERL Y_CONTAINED_IN  the_rms  =>  (EXISTS  z:  rm)  y  CONTAINED_IN  z] 
rm_location :  CONSTRAINT  = 

(FORALL  y:  rm)  y  CONTAINED_IN  the_rms 


ar_l:  CONSTRAINT  = 

(FORALL  y:  rm)  (EXISTS  w:  ap_ar_aux)  Called_From(y.access_function,  w) 
ar_2:  CONSTRAINT  = 

(FORALL  w:  ap_ar_aux)  (EXISTS  y:  rm)  Called_From(y . access_function,  w) 
tx:  CONSTRAINT  = 

Called_From(the_tm_main. begin,  the_ap_tx_aux) 

AND  Called_From(the_tm_main. close,  the_ap_tx_aux) 

AND  Called_From(the_tm_main. commit,  the_ap_tx_aux) 

AND  Called_From(the_tm_main. information,  the_ap_tx_aux) 

AND  Called_From(the_tm_main.open,  the_ap_tx_aux) 

AND  Called_From(the_tm_main. rollback,  the_ap_tx_aux) 

xa_l:  CONSTRAINT  = 

(FORALL  y:  rm) (EXISTS  w:  tm_aux) 

[Called_From(w. register,  y) 

AND  Called_From(w.iinregister,  y) 

AND  Called_From(y. close,  w) 

AND  Called_From(y. commit,  w) 

AND  Called_From(y. complete,  w) 

AND  Called_From(y.end,  w) 

AND  Called_From(y. forget,  w) 
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AND  Called_From(y.open,  w) 

AND  Called_Froni(y. prepare,  w) 

AND  Called_Froin(y. recover,  w) 

AND  Called_From(y. rollback,  w) 

AND  Called_From(y. start,  w) ] 

xa_2:  CONSTRAINT  = 

(FORALL  w:  tm_avix)  (EXISTS  y:  rm) 

[Called_From(w. register,  y) 

AND  Called_Froin(w. unregister,  y) 

AND  Called_Froin(y. close,  w) 

AND  Called_From(y. commit,  w) 

AND  Called_From(y. complete,  w) 

AND  Called_From(y.end,  w) 

AND  Cal led_From(y. forget,  w) 

AND  Called_From{y.open,  w) 

AND  Called_From(y. prepare,  w) 

AND  Called_From{y. recover,  w) 

AND  Called_From(y. rollback,  w) 

AND  Called_From(y. start,  w) ] 

intra_ap_l:  CONSTRAINT  = 

(FORALL  w:  ap_ar_aux)  Called_From(w.access_function,  the_ap_main) 

intra_ap_2s  CONSTRAINT  = 

Called_From ( the_ap_tx_aux . begin,  the_ap ) 

AND  Cal led_From ( the_ap_tx_aux .close,  the_ap ) 

AND  Cal led_From ( the_ap_tx_aux . commi t ,  the_ap ) 

AND  Called_From(the_ap_tx_aux. information,  the_ap) 

AND  Cal led_From(the_ap_tx_aux. open,  the_ap) 

AND  Cal led_From(the_ap_tx_aux. rollback,  the_ap) 

intra_tm:  CONSTRAINT  = 

(FORALL  w:  tm_aux) 

[Called_From ( the_tm_main . register ,  w) 

AND  Called_From(the_tm_main.vinregister,  w) 

AND  Called_From(w. close,  the_tm_main) 

AND  Called_From(w. commit,  the_tm_main) 

AND  Called_From(w. complete,  the_tm_main) 

AND  Called_From(w.end,  the_tm_main) 

AND  Called_From(w. forget,  the_tm_main) 

AND  Called_From(w.open,  the_tm_main) 

AND  Cal led_From(w. prepare,  the_tm_main) 

AND  Cal led_From ( w . recover ,  the_tm_main ) 

AND  Called_From(w. rollback,  the_tm_main) 

AND  Called_From(w. start,  the_tm_main) ] 


END  x_open_ap_aux_decomposition 


%%%  Now  we  shoot  for  the  dual  to  example-13,  breaking  out  the  auxiliary 
%%%  processes  on  the  RM  side  rather  than  the  AP  side. 

x_open_manager_decomposition:  ARCHITECTURE  [  ->  ] 

IMPORTING  ALL  FROM  X_Open_style 

BEGIN 

n:  NAT  %  Number  of  resource  managers,  a  parameter  in  the  specification 
ar_requests ,  ar_resources :  TYPE 
COMPONENTS 

ap:  TYPE  <=  ARCHITECTURE  [  ->  ] 

rm_ar_aux:  TYPE  <=  {  m:  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 

access_f unction:  PROCEDURE  [in:  qt  ->  out:  rt] 
END  m 

I  qt  <  ar_requests  AND  rt  <  ar_resources  } 

rm_xa_aux:  TYPE  <=  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 

close:  XA_Close_Procedure 

[info:  XA_lnfo,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

commit :  XA_Commit_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

complete:  XA_Complete_Procedure 

[hndl:  INT,  retval:  INT, 

rmid:  INT,  flags:  INT 
->  ret:  INT] 
end :  XA_End_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

forget :  XA_Porget_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 
open :  XA_Open_Procedure 

[info:  XA_Info,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

prepare :  XA_Prepare_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

recover :  XA_Recover_Procedure 

[ ids :  X_Ids ,  count :  INT , 

rmid:  INT,  flags:  INT 
->  ret:  INT] 

rollback:  XA_Rollback_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

start:  XA_Start_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

END  rm_xa_aux 

rm_main:  TYPE  <=  {  m:  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 
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access_f unction:  RPC  [in:  qt  ->  out:  rt] 
close:  RPC 

[info:  XA_Info,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

commit :  RPC 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 
complete :  RPC 

[hndl:  INT,  retval:  INT, 

rmid;  INT,  flags:  INT 
->  ret:  INT] 

end :  RPC 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

forget :  RPC 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

open :  RPC 

[info:  XA_Info,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

prepare :  RPC 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

recover :  RPC 

[ids:  X_Ids,  count:  INT, 

rmid:  INT,  flags:  INT 
->  ret;  INT] 
rollback:  RPC 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

start :  RPC 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

END  m 

I  qt  <  ar_requests  AND  rt  <  ar_resources  } 

rms:  TYPE  <=  ARCHITECTURE  [  ->  ] 

tm_aux:  TYPE  <=  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 

begin:  TX_Begin_Procedure  [  ->  ret:  INT] 

close:  TX_Close_Procedure  [  ->  ret:  INT] 

commit:  TX_Commit_Procedure  [  ->  ret:  INT] 

information:  TX_Info_Procedure  [info:  TX_Info  ->  ret:  INT] 

open;  TX_Open_Procedure  [  ->  ret:  INT] 

rollback:  TX_Rollback_Procedure  [  ->  ret:  INT] 

END  tm_aux 

tm_main:  TYPE  <=  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 

register:  AX_Register_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret;  INT] 

unregister ;  AX_Unregister_Procedure 
[rmid:  INT,  flags:  INT 
->  ret :  INT] 

begin:  RPC  [  ->  ret:  INT] 
close:  RPC  [  ->  ret:  INT] 
commit:  RPC  [  ->  ret:  INT] 

information:  RPC  [info:  TX_Info  ->  ret:  INT] 
open:  RPC  [  ->  ret:  INT] 
rollback:  RPC  [  ->  ret:  INT] 
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END  tm_inain 


the_ap :  ap 

the_rms :  rms 
the_tm :  tm 
the_tin_inain :  tm_inain 
the_tm_aux :  tin_aux 

CONFIGURATION 

rms_contents :  CONSTRAINT  = 

(FORALL  y:  COMPONENT) 

[y  PROPERLY_CONTAINED_IN  the_rms 

=>  (EXISTS  z:  nn_main)  y  CONTAINED_IN  z 

OR  (EXISTS  z:  nii_ar_aux)  y  CONTAINED_IN  z 
OR  (EXISTS  z:  nn_xa_aux)  y  CONTAINED_IN  z] 
nn_main_location:  CONSTRAINT  = 

(FORALL  y:  rm_main)  y  CONTAINED_IN  the_rms 
nn_ar_aux_location:  CONSTRAINT  = 

(FORALL  y:  rm_ar_aux)  y  CONTAINED_IN  the_nns 
nn_xa_a\ix_location:  CONSTRAINT  = 

(FORALL  y:  rm_xa_aux)  y  CONTAINED_IN  the_nns 


ar:  CONSTRAINT  = 

(FORALL  u;  nn_ar_aux)  Called_From(u.access_function,  the_ap) 

tx;  CONSTRAINT  = 

Called_Froin ( the_tm_aux . begin,  the_ap) 

AND  Cal led_Froni(the_tm_aux. close,  the_ap) 

AND  Called_Froni(the_tm_aux.coiranit,  the_ap) 

AND  Called_Froin(the_tin_a\ix. information,  the_ap) 

AND  Called_From(the_tm_aux.open,  the_ap) 

AND  Called_From(the_tm_aux. rollback,  the_ap) 

xa:  CONSTRAINT  = 

( FORALL  V :  rm_xa_aux ) 

[Called_From(the_tm. register,  v) 

AND  Called_From(the_tm. unregister,  v) 

AND  Called_From(v. close,  the_tm) 

AND  Called_From(v. commit,  the_tm) 

AND  Called_From(v. complete,  the_tm) 

AND  Called_From(v.end,  the_tm) 

AND  Called_From(v. forget,  the_tm) 

AND  Called_From(v.open,  the_tm) 

AND  Cal led_From(v. prepare,  the_tm) 

AND  Called_From(v. recover,  the_tm) 

AND  Called_From(v. rollback,  the_tm) 

AND  Called_From(v. start,  the_tm) ] 

intra_tm:  CONSTRAINT  = 

Called_From ( the_tm_main . begin,  the_tm_aux) 

AND  Called_From(the_tm_main. close,  the_tm_aux) 

AND  Called_From(the_tm_main. commit,  the_tm_aux) 

AND  Called_From(the_tm_main. information,  the_tm_a\ix) 

AND  Called_From(the_tm_main.open,  the_tm_aux) 

AND  Called_From(the_tm_main. rollback,  the_tm_aux) 

intra_rm_l:  CONSTRAINT  = 

(FORALL  y:  rm_main)  (EXISTS  u:  rm_ar_aux) 
Called_From(y.access_f unction,  u) 

intra_rm_2 :  CONSTRAINT  = 

(FORALL  u:  rm_ar_aux)  (EXISTS  y:  rm_main) 
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Called_From(y.access_fiinction,  u) 

intra_nn_3:  CONSTRAINT  = 

(FORALL  y:  rm_main)  (EXISTS  v:  nn_xa_aux) 
[Called_From(v. register ,  y) 

AND  Cal led_Froin(v. unregister,  y) 

AND  Called_From{y. close,  v) 

AND  Called_Froin(y. commit,  v) 

AND  Called_From(y. complete,  v) 

AND  Called_From(y.end,  v) 

AND  Called_From(y. forget,  v) 

AND  Called_From(y . open,  v) 

AND  Called_From(y .prepare,  v) 

AND  Cal led_From{y. recover,  v) 

AND  Called_From(y. rollback,  v) 

AND  Called_From(y. start,  v) ] 

intra_rm_4:  CONSTRAINT  = 

(FORALL  v:  rm_xa_aux)  (EXISTS  y:  rm_main) 
[Called_From(v. register,  y) 

AND  Called_From(v. unregister,  y) 

AND  Called_From(y. close,  v) 

AND  Called_From(y. commit,  v) 

AND  Called_From(y. complete,  v) 

AND  Called_From(y.end,  v) 

AND  Called_From(y. forget,  v) 

AND  Called_From(y.open,  v) 

AND  Called_From(y .prepare,  v) 

AND  Called_From(y. recover,  v) 

AND  Called_From(y. rollback,  v) 

AND  Called_From(y. start,  v) ] 

END  x_open_manager_decomposition 
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%%%  similar  to  example-14,  but  collapses  auxiliary  processes  in  RM.  Dual 
%%%  to  example-12  in  much  the  way  example-14  is  dual  to  example-13 . 

x_open_manager_alt_decomposition:  ARCHITECTURE  [  ->  ] 

IMPORTING  ALL  FROM  X_Open_style 

BEGIN 

n:  NAT  %  Number  of  resource  managers,  a  parameter  in  the  specification 
ar_requests,  ar_resources :  TYPE 
resource_id:  TYPE  =  {  i;  NAT  |  i  <  n  } 

COMPONENTS 


ap:  TYPE  <=  ARCHITECTURE  [  ->  ] 


rm_ar_aux:  TYPE  <=  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 

parameterized_access_function : 

PROCEDURE  [r_id:  resource_id,  in:  qt  ->  out:  rt] 
END  rm_ar_aux 


%%  Note  that  the  following  already  contain  the  necessary  RM  id  args . 
rm_xa_aux:  TYPE  <=  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 

close :  XA_Close_Procedure 

[info:  XA_Info,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

commit:  XA_Commit_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

complete :  XA_Complete_Procedure 

[hndl:  INT,  retval:  INT, 

rmid:  INT,  flags:  INT 
->  ret:  INT] 

end :  XA_End_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

forget:  XA_Forget_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 


->  ret:  INT] 

open :  XA_Open_Procedure 

[info:  XA_Info,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

prepare :  XA_Prepare_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

recover:  XA_Recover_Procedure 

[ ids :  X_Ids ,  count :  INT , 

rmid:  INT,  flags:  INT 
->  ret:  INT] 

rollback:  XA_Rollback_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 


->  ret:  INT] 

start :  XA_Start_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 


END  rm_xa_aux 
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nn_main:  TYPE  <=  {  m:  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 

access_f unction:  RPC  [in:  qt  ->  out:  rt] 
close:  RPC 

[info:  XA_Info,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

commit:  RPC 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 
complete :  RPC 

[hndl:  INT,  retval:  INT, 

rmid:  INT,  flags:  INT 
->  ret:  INT] 

end:  RPC 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

forget :  RPC 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

open :  RPC 

[info:  XA_Info,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

prepare :  RPC 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

recover :  RPC 

[ids:  X_Ids,  count:  INT, 

rmid:  INT,  flags:  INT 
->  ret:  INT] 
rollback:  RPC 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

start:  RPC 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

END  m 

I  qt  <  ar_requests  AND  rt  <  ar_resources  ) 

rms:  TYPE  <=  ARCHITECTURE  [  ->  ] 

tm_aux:  TYPE  <=  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 

begin:  TX_Begin_Procedure  [  ->  ret:  INT] 

close:  TX_Close_Procedure  [  ->  ret:  INT] 

commit:  TX_Commit_Procedure  [  ->  ret:  INT] 

information:  TX_Info_Procedure  [info:  TX_Info  ->  ret:  INT] 

open:  TX_Open_Procedure  [  ->  ret:  INT] 

rollback:  TX_Rollback_Procedure  [  ->  ret:  INT] 

END  tm_aux 

tm_main:  TYPE  <=  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 

register:  AX_Register_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

unregister :  AX_Unregister_Procedure 
[rmid:  INT,  flags:  INT 
->  ret:  INT] 

begin:  RPC  [  ->  ret:  INT] 
close:  RPC • [  ->  ret:  INT] 
commit:  RPC  [  ->  ret:  INT] 
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information:  RPC  [info:  TX_Info  ->  ret:  INT] 
open:  RPC  [  ->  ret:  INT] 
rollback:  RPC  [  ->  ret:  INT] 

END  tm_main 


the_ap :  ap 
the_rms :  rms 

the_rm_ar_aux :  rm_ar_aux 
the_rm_xa_aux :  rm_xa_aux 
the_tm:  tm 

the_tm_main:  tm_main 
the_tm_aux :  tm_aux 

CONFIGURATION 

rms_contents :  CONSTRAINT  = 

(FORALL  y:  COMPONENT) 

[y  PROPERL Y_CONTAINED_IN  the_rms 

=>  (EXISTS  z:  rm_main)  y  CONTAINED_IN  z 
OR  y  CONTAINED_IN  the_rm_ar_aux 
OR  y  CONTAINED_IN  the_rm_xa_aux] 
rm_main_location:  CONSTRAINT  = 

(FORALL  y:  rm_main)  y  CONTAINED_IN  the_rms 
rm_ar_aux_location:  CONSTRAINT  = 

the_rm_ar_aux  CONTAINEp_IN  the_rms 
rm_xa_aux_location:  CONSTRAINT  = 

the_rm_xa_aux  CONTAINED_IN  the_rms 


ar:  CONSTRAINT  = 

Called_From ( the_rm_ar_aiix . access_function,  the_ap ) 
tx:  CONSTRAINT  = 

Cal  led_From  ( the_tm_axax .  begin ,  the_ap ) 

AND  Called_From(the_tm_a\ix. close,  the_ap) 

AND  Called_From  ( the_tm_a\ix .  commit ,  the_ap ) 

AND  Cal led_From(the_tm_aux. information,  the_ap) 

AND  Called_From(the_tm_aux.open,  the_ap) 

AND  Called_From(the_tm_aux. rollback,  the_ap) 

xa:  CONSTRAINT  = 

Called_From ( the_tm. register ,  the_rm_xa_aux) 

AND  Cal led_From(the_tm. unregister,  the_rm_xa_aux) 

AND  Called_From(the_rm_xa_aux. close,  the_tm) 

AND  Called_From(the_rm_xa_aux. commit,  the_tm) 

AND  Called_From(the_rm_xa_aux. complete,  the_tm) 

AND  Called_From(the_rm_xa_aux.end,  the_tm) 

AND  Called_From(the_rm_xa_aux. forget,  the_tm) 

AND  Call ed_Fr om ( the_rm_xa_aux . open ,  the_tm ) 

AND  Cal led_From(the_rm_xa_aux. prepare,  the_tm) 

AND  Called_From(the_rm_xa_aux. recover,  the_tm) 

AND  Cal led_From(the_rm_xa_aux. rollback,  the_tm) 

AND  Cal led_From(the_rm_xa_aux. start,  the_tm) 

intra_tm:  CONSTRAINT  = 

Cal led_From ( the_tm_main . begin ,  the_tm_aux ) 

AND  Called_From(the_tm_main. close,  the_tm_aux) 

AND  Called_From(the_tm_main. commit,  the_tm_aux) 

AND  Called_From(the_tm_main. information,  the_tm_aux) 
AND  Cal led_From ( the_tm_main . open ,  the_tm_aux ) 

AND  Called_From(the_tm_main. rollback,  the_tm_aux) 


intra_rm_l:  CONSTRAINT  = 
(FORALL  y:  rm_main) 
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Cal led_Froin  ( y . acces s_f unction ,  the_rm_ar_aux ) 

intra_rm_2:  CONSTRAINT  = 

(FORALL  y:  nn_main) 

[Called_Froin ( the_rm_xa_aux . register,  y) 

AND  Called_From(the_nn_xa_aux. unregister,  y) 
AND  Called_Froin(y. close,  the_rm_xa_aux) 

AND  Called_From(y. commit,  the_rm_xa_aux) 

AND  Called_From(y. complete,  the_rm_xa_aux) 
AND  Called_From(y.end,  the_rm_xa_aux) 

AND  Cal led_From{y. forget,  the_rm_xa_aux) 

AND  Called_From(y.open,  the_rm_xa_aux) 

AND  Called_From(y. prepare,  the_rm_xa_aux) 
AND  Called_From(y. recover,  the_rm_xa_aiix) 
AND  Called_From(y. rollback,  the_rm_xa_aux) 
AND  Cal led_From ( y . s  tart ,  the_rm_xa_aux ) ] 

END  x_open_manager_alt_decomposition 
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%%%  Just  like  14,  but  an  extra  layer  of  abstraction  in  the  RM  to  simplify 
%%%  the  mapping. 

x_open_manager_decomposition_2 :  ARCHITECTURE  [  ->  ] 

IMPORTING  ALL  FROM  X_Open_style 
BEGIN 

n:  NAT  %  Niimber  of  resource  managers,  a  parameter  in  the  specification 
ar_requests,  ar_resources :  TYPE 
COMPONENTS 

ap:  TYPE  <=  ARCHITECTURE  [  ->  ] 

rm_ar_aux:  TYPE  <=  {  m:  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 

access_f unction :  PROCEDURE  [in:  qt  ->  out:  rt] 
END  m 

I  qt  <  ar_requests  AND  rt  <  ar_resources  } 

rm_xa_aux:  TYPE  <=  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 

close:  XA_Close_Procedure 

[info:  XA_Info,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

commit:  XA_Commit_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

complete :  XA_Complete_Procedure 

[hndl:  INT,  retval:  INT, 

rmid:  INT,  flags:  INT 
->  ret:  INT] 
end :  XA_End_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

forget :  XA_Forget_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 
open :  XA_Open_Procedure 

[info:  XA_Info,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

prepare :  XA_Prepare_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

recover :  XA_Recover_Procedure 

[ids:  X_Ids,  count:  INT, 

rmid:  INT,  flags:  INT 
->  ret:  INT] 

rollback:  XA_Rollback_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

start:  XA_Start_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

END  rm_xa_aux 

rm_main:  TYPE  <=  {  m:  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 
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access_f unction:  RPC  [in:  qt  ->  out:  rt] 
close:  RPC 

[info:  XA_Info,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

commit:  RPC 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 
complete :  RPC 

[hndl:  INT,  retval:  INT, 

rmid:  INT,  flags:  INT 
->  ret:  INT] 

end :  RPC 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

forget:  RPC 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

open :  RPC 

[info:  XA_Info,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

prepare :  RPC 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

recover ;  RPC 

[ids:  X_Ids,  count:  INT, 

rmid:  INT,  flags:  INT 
->  ret:  INT] 
rollback:  RPC 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

start :  RPC 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

END  m 

I  qt  <  ar_requests  AND  rt  <  ar_resources  } 

rm:  TYPE  <=  ARCHITECTURE  [  ->  ] 

rms;  TYPE  <=  ARCHITECTURE  [  ->  ] 

tm_aux:  TYPE  <=  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL ' 

BEGIN 

begin:  TX_Begin_Procedure  [  ->  ret:  INT] 

close:  TX_Close_Procedure  [  ->  ret:  INT] 

commit:  TX_Commit_Procedure  [  ->  ret:  INT] 

information:  TX_Info_Procedure  [info:  TX_Info  ->  ret:  INT] 

open:  TX_Open_Procedure  [  ->  ret:  INT] 

rollback:  TX_Rollback_Procedure  [  ->  ret:  INT] 

END  tm_aux 

tm_main:  TYPE  <=  ARCHITECTURE  [  ->  ] 

EXPORTING  ALL 
BEGIN 

register:  AX_Register_Procedure 

[id:  X_Id,  rmid:  INT,  flags:  INT 
->  ret:  INT] 

unregister:  AX_Unregister_Procedure 
[rmid:  INT,  flags:  INT 
->  ret:  INT] 

begin:  RPC  [  ->  ret:  INT] 
close:  RPC  [  ->  ret:  INT] 
commit:  RPC  [  ->  ret:  INT] 

information:  RPC  [info:  TX_Info  ->  ret:  INT] 
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open:  RPC  [  ->  ret:  INT] 
rollback:  RPC  [  ->  ret;  INT] 
END  tni_inain  . 


the_ap :  ap 
the_rms :  rms 
the_tin:  tm 

the_tm_main:  tm_main 
the_tin_aiix :  tm_aux 

CONFIGURATION 

rms_contents :  CONSTRAINT  = 

(FORALL  y:  COMPONENT) 

[y  PROPERLy_CONTAINED_IN  the_rms  =>  (EXISTS  z:  rm)  y  CONTAINED_IN  z] 

nn_contents:  CONSTRAINT  = 

(FORALL  y:  COMPONENT) 

[(EXISTS  z:  rm)  y  PROPERLY_CONTAINED_IN  z 

=>  (EXISTS  z:  rm_main)  y  CONTAINED_IN  z 

OR  (EXISTS  z:  rm_ar_aux)  y  CONTAINED_IN  z 
OR  (EXISTS  z:  rm_xa_aux)  y  CONTAINED_IN  z] 

rm_location:  CONSTRAINT  = 

(FORALL  y:  rm)  y  CONTAINED_IN  the_rms 

rm_main_location_l ;  CONSTRAINT  = 

(FORALL  y;  rm_main)  (EXISTS  z:  rm)  y  CONTAINED_IN  z 
rm_main_location_2 :  CONSTRAINT  = 

(FORALL  z:  rm)  (EXISTS  y:  rm_main)  y  CONTAINED_IN  z 

rm_ar_a\ix_location_l :  CONSTRAINT  = 

(FORALL  y:  rm_ar_aux)  (EXISTS  z:  rm)  y  CONTAINED_IN  z 
rm_ar_aux_location_2 :  CONSTRAINT  = 

(FORALL  z:  rm)  (EXISTS  y;  rm_ar_a\ix)  y  CONTAINED_IN  z 

rm_xa_aux_location_l :  CONSTRAINT  = 

(FORALL  y:  rm_xa_aux)  (EXISTS  z:  rm)  y  CONTAINED_IN  z 
rm_xa_aux_location_2 :  CONSTRAINT  = 

(FORALL  z:  rm)  (EXISTS  y;  rm_xa_aux)  y  CONTAINED_IN  z 


ar:  CONSTRAINT  = 

(FORALL  u:  rm_ar_aux)  Called_From(u.access_function,  the_ap) 
tx:  CONSTRAINT  = 

Cal led_From ( the_tm_aux . begin ,  the_ap ) 

AND  Called_From(the_tm_aux. close,  the_ap) 

AND  Called_From(the_tm_aux. commit,  the_ap) 

AND  Called_From(the_tm_aux. information,  the_ap) 

AND  Called_From(the_tm_aux.open,  the_ap) 

AND  Called_From(the_tm_aux. rollback,  the_ap) 

xa:  CONSTRAINT  = 

(FORALL  v:  rm_xa_aux) 

[Called_From(the_tm. register,  v) 

AND  Called_From(the_tm. unregister,  v) 

AND  Called_From(v. close,  the_tm) 

AND  Called_From(v. commit,  the_tm) 

AND  Called_From(v. complete,  the_tm) 

AND  Called_From(v. end,  the_tm) 

AND  Called_From(v. forget,  the_tm) 

AND  Called_From(v. open,  the_tm) 

AND  Called_From(v. prepare,  the_tm) 
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AND  Called_Froin(v. recover,  the_tm) 

AND  Called_From{v. rollback,  the_tm) 

AND  Called_From(v. start,  the_tm) ] 

intra_tm:  CONSTRAINT  = 

Called_Froin  ( the_tin_main .  begin ,  the_tm_aux) 

AND  Called_From(the_tin_main. close,  the_tin_aux) 

AND  Called_From(the_tm^main. commit,  the_tm_aux) 

AND  Called_From(the_tm_main. information,  the_tm_aux) 
AND  Cal led_From ( the_tm_main . open ,  the_tm_aux ) 

AND  Called_From(the_tm_main. rollback,  the_tm_aux) 

intra_rm_l:  CONSTRAINT  = 

(FORALL  y:  rm_main)  (EXISTS  u:  rm_ar_aiix) 
Called_From(y.access_function,  u) 

intra_rm_2:  CONSTRAINT  = 

(FORALL  u:  rm_ar_aux)  (EXISTS  y:  rm_main) 
Called_From(y.access_f unction,  u) 

intra_rm_3:  CONSTRAINT  = 

(FORALL  y:  rm_main)  (EXISTS  v:  rm_xa_aux) 
[Called_From(v. register,  y) 

AND  Called_From(v. unregister,  y) 

AND  Called_From(y. close,  v) 

AND  Called_From(y .commit,  v) 

AND  Called_From(y. complete,  v) 

AND  Called_From(y.end,  v) 

AND  Called_From(y. forget,  v) 

AND  Cal led_From(y .open,  v) 

AND  Called_From(y. prepare,  v) 

AND  Called_From(y. recover,  v) 

AND  Called_From(y. rollback,  v) 

AND  Called_From(y. start,  v) ] 

intra_rm_4:  CONSTRAINT  = 

(FORALL  v:  rm_xa_aux)  (EXISTS  y:  rm_main) 
[Called_From(v. register,  y) 

AND  Called_From(v. unregister,  y) 

AND  Called_From(y. close,  v) 

AND  Called_From(y. commit,  v) 

AND  Called_From(y. complete,  v) 

AND  Called_From(y,end,  v) 

AND  Called_From(y. forget,  v) 

AND  Called_From(y.open,  v) 

AND  Called_From(y .prepare,  v) 

AND  Called_From(y. recover,  v) 

AND  Called_From(y. rollback,  v) 

AND  Called_From(y. start,  v) ] 

END  x_open_manager_decompos i t ion_2 


61 


B  SRI  Publications:  Correct  Architecture  Refinement 


62 


Appeared  in  IEEE  Transactions  on  Software  Engineering, 
April,  1995,  Volume  21,  Number  4,  pp.  356-372. 


Correct  Architecture  Refinement 

Mark  Moriconi,  Xiaolei  Qian,  and  R.  A.  Riemenschneider 


Abstract —  A  method  is  presented  for  the  stepwise  refine¬ 
ment  of  an  abstract  architecture  into  a  relatively  correct 
lower-level  architecture  that  is  intended  to  implement  it.  A 
refinement  step  involves  the  application  of  a  predefined  re¬ 
finement  pattern  that  provides  a  routine  solution  to  a  stan¬ 
dard  architectural  design  problem.  A  pattern  contains  an 
abstract  architecture  schema  and  a  more  detailed  schema 
intended  to  implement  it.  The  two  schemas  usually  contain 
very  different  architectural  concepts  (from  different  archi¬ 
tectural  styles).  Once  a  refinement  pattern  is  proven  cor¬ 
rect,  instances  of  it  can  be  used  without  proof  in  developing 
specific  architectures.  Individual  refinements  are  composi¬ 
tional,  permitting  incremental  development  and  local  rea¬ 
soning.  A  special  correctness  criterion  is  defined  for  the  do¬ 
main  of  software  surchitecture,  as  well  as  an  accompanying 
proof  technique.  A  useful  syntactic  form  of  correct  compo¬ 
sition  is  defined.  The  main  points  are  illustrated  by  means 
of  familiar  architectures  for  a  compiler.  A  prototype  imple¬ 
mentation  of  the  method  has  been  used  successfully  in  a  real 
application. 

Keywords —  Software  architecture,  hierarchy,  stepwise  re¬ 
finement,  refinement  patterns,  formal  methods,  relative  cor¬ 
rectness,  composition 

I.  Introduction 

ECISIONS  about  the  architecture  of  a  software  sys¬ 
tem  can  have  a  major  impact  on  system  efficiency, 
maintainability,  and  evolvability.  Architectural  decisions 
typically  are  documented  in  terms  of  the  ubiquitous  box- 
and-arrow  diagrams.  Practicing  engineers  interpret  the  di¬ 
agrams  with  respect  to  common  architectural  styles,  such 
as  datsdlow,  pipe-and-filter,  batch-sequential,  blackboard, 
implicit  invocation  (event-based),  and  client-server. 

For  a  large  system,  its  architecture  often  is  described  by 
a  hierarchy  of  related  architectures.  An  architecture  hierar¬ 
chy  is  a  lineetr  sequence  of  two  or  more  individual  surchitec- 
tures  that  may  differ  with  respect  to  the  number  and  kind 
of  components  and  connections  among  them.  For  example, 
an  abstract  architecture  contmning  functional  components 
related  by  dataflow  connections  may  be  implemented  in  a 
concrete  architecture  in  terms  of  procedures,  control  con¬ 
nections,  and  shared  variables.  In  general,  an  abstract  ar¬ 
chitecture  is  smaller  and  easier  to  understand;  a  concrete 
architecture  reflects  more  implementation  concerns. 

The  utility  of  an  architecture  hierarchy  is  severely  lim¬ 
ited  by  the  current  level  of  informality.  Individual  architec¬ 
tures  may  be  ambiguous,  allowing  multiple  and  perhaps  un¬ 
intended  interpretations.  The  mapping  between  architec¬ 
tures  in  the  hierarchy  is  partially  specified,  if  at  all,  making 
it  impossible  to  accurately  trace  the  lineage  of  implemen¬ 
tation  decisions.  The  analysis  of  architecture  is  limited  to 
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syntactic  checks.  It  is  not  possible  to  check  semantic  prop¬ 
erties  of  an  architecture,  such  as  the  safety  and  fairness  of 
its  connections,  or  to  check  the  relative  correctness  of  two 
architectures  in  the  hierarchy.  Consequently,  a  concrete  ar¬ 
chitecture  may  erroneously  be  seen  as  an  implementation 
of  a  more  abstract  architecture. 

The  main  contribution  in  this  paper  is  a  methodology 
for  the  correct  stepwise  refinement  of  software  architec¬ 
tures.  It  is  expected  to  lead  to  fewer  architectural  design 
errors,  to  extensive  and  systematic  reuse  of  design  knowl¬ 
edge  and  proofs,  and  ultimately  to  an  architecture  synthesis 
tool  similar  to  those  now  used  for  integrated  circuit  design. 
The  methodology  involves  the  use  of  instances  of  Mchi- 
tecture  refinement  patterns  that  are  correctness  preserving 
and  compositional. 

A  refinement  pattern  provides  a  routine  solution  to  a 
standard  architectural  design  problem.  For  example,  a  pat¬ 
tern  may  show  how  to  implement  a  single  dataflow  connec¬ 
tion  in  shared  memory,  or  several  patterns  may  combine 
to  implement  dataflow  diagrams  in  terms  of  some  form  of 
client/server  architecture.  A  pattern  cont£iins  a  pair  of  ar¬ 
chitecture  schemas  that  are  proved  to  be  relatively  correct 
with  respect  to  a  given  mapping  schema  between  them. 
The  proof  is  performed  only  once;  every  instance  of  a  re¬ 
finement  pattern  is  guaranteed  to  be  correct.  A  schema 
can  be  homogeneous  (consisting  of  one  style)  or  heteroge¬ 
neous  (consisting  of  multiple  styles).  The  two  schemas  in  a 
refinement  pattern  may,  and  usually  do,  contain  concepts 
from  different  architectural  styles. 

A  useful  form  of  correctness-preserving  composition  is 
defined  that  applies  to  both  individual  refinements  and  ex¬ 
isting  architectures.  The  latter  is  important  because  we 
want  to  be  able  to  assemble  existing  subsystem  architec¬ 
tures  into  a  single  system.  Two  architectures  can  be  com¬ 
posed  even  if  their  vocabularies  are  not  disjoint.  In  gen¬ 
eral,  “horizontal”  composition  requires  a  case-by-case  proof 
of  correctness.  However,  we  define  a  simple  syntactic  cri¬ 
terion  that,  if  satisfied,  guarantees  compositionality.  Be¬ 
cause  our  correctness  relation  is  transitive,  the  “vertical” 
composition  of  levels  in  an  architecture  hierarchy  preserves 
correctness,  and  we  are  guaranteed  that  the  most  concrete 
architecture  in  the  hierarchy  meets  the  requirements  of  the 
most  abstract  architecture  in  the  hierMchy. 

The  correctness  of  architecture  refinement  and  compo¬ 
sition  involves  a  special  correctness  criterion,  which  is 
stronger  than  the  usual  one  for  functional  refinement,  and 
a  special  mapping  between  architectures,  that  is  more  com¬ 
plex  than  the  usual  mapping  between  data  structures.  A 
mapping  between  architectures  involves  an  extensive  trans¬ 
lation  in  which  the  representation  of  components,  inter¬ 
faces,  and  connections  may  change  and,  moreover,  these 
abstract  objects  may  be  aggregated,  decomposed,  or  elim- 
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inated  in  the  concrete  architecture. 

A  stronger  correctness  criterion  is  needed  because  of  the 
potential  uses  of  architectures.  Consider  the  role  an  archi¬ 
tecture  can  play  in  reducing  the  time  to  provide  fixes,  opti¬ 
mizations,  and  upgrades  to  systems  in  deployment.  If  the 
architecture  accurately  models  the  implementation,  it  can 
be  used  to  focus  and  explore  the  consequences  of  changes 
to  the  implementation.  But  if  the  implementation  con¬ 
tains  connections  that  do  not  appear  in  the  architecture, 
a  developer  could  easily  be  misled  into  making  changes 
that  appear  to  be  minor  and  localized  but  that,  in  fact, 
have  widespread  consequences.  For  example,  we  may  spec¬ 
ify  a  pipeline  architecture,  restricting  the  system  topol¬ 
ogy  to  a  lineeir  sequence  of  filters,  to  facilitate  component 
reusability.  If  the  concrete  architecture  implements  the 
pipeline,  but  additionally  introduces  feedback  loops,  the 
raison  d’etre  behind  the  original  pipeline  architecture  is  no 
longer  valid.  In  general,  the  preservation  of  “communica¬ 
tion  integrity”  is  integral  to  the  utility  of  an  architecture. 

Therefore,  an  architecture  should  describe  explicitly  the 
components,  interfaces,  and  connections  that  are  required 
of  the  target  system,  and  perhaps  more  importantly,  those 
that  are  not  intended  to  appear  in  the  target  system.  This 
observation  leads  to  a  completeness  assumption  about  a 
given  architecture,  namely  that  an  architecture  contains 
all  components,  interfaces,  and  connections  intended  to  be 
true  of  the  architecture  at  its  level  of  detail.  If  a  fact  is 
not  explicit  in  the  architecture,  or  deducible  from  it,  we 
assume  that  it  is  not  intended  to  be  true  of  the  architecture. 
In  the  pipeline  example,  we  couple  the  linearity  property 
with  the  completeness  assumption  to  infer  that  no  feedback 
loop  is  allowed  in  an  implementation  of  the  architecture. 
In  general,  an  architecture  (whether  static  or  dynamic)  can 
contain  ein  unbounded  number  of  facts. 

The  completeness  assumption  requires  that  we  prove  not 
only  that  a  concrete  architecture  does  not  lose  properties 
of  the  abstract  architecture,  but  also  that  no  new  proper¬ 
ties  about  the  abstract  surchitecture  can  be  inferred  from 
the  concrete  architecture.  The  standard  method  for  rea¬ 
soning  about  the  relative  correctness  of  two  specifications 
is  to  show  that  the  concrete  specification  logically  implies 
the  abstract  specification  under  a  given  mapping  between 
them.  This  allows  an  implementation  to  exhibit  additional, 
unspecified  behaviors,  as  long  as  the  specified  behavior  is 
implemented.  If  the  standard  proof  method  is  applied  to 
architectures,  there  would  be  no  guarantee  that  negative 
properties  tire  preserved  under  refinement. 

Fortunately,  there  is  a  well-understood  mathematiccil 
property,  called  faithful  interpretation,  that  Ccm  be  adapted 
for  our  purposes.  If  a  certain  mapping  between  the  two  ar¬ 
chitectures  is  faithful,  both  the  positive  and  the  implicit 
negative  facts  in  the  abstract  architecture  are  preserved 
in  the  concrete  architecture.  However,  a  proof  of  faith¬ 
fulness  is  inherently  hard,  cind  we  are  not  aware  of  any 
general  proof  technique  in  the  literature.  We  introduce  a 
systematic  technique  for  proving  frdthfulness.  The  inherent 
complexity  of  such  proofs  is  one  reeison  why  we  advocate  a 
methodology  that  makes  use  of  preproved  refinement  pat¬ 


terns. 

It  is  worth  mentioning  that  an  important  consequence 
of  the  completeness  assumption  is  that  the  st£mdard  step¬ 
wise  refinement  paradigm  is  unsound  with  respect  to  the 
correctness  relation.  Certain  refinements  of  an  Mchitec- 
ture  must  be  composed  horizontally.  Completed  levels  in 
an  architecture  hierarchy  can  be  composed  vertically. 

This  paper  is  organized  as  follows.  The  next  section  il¬ 
lustrates  the  refinement  problem  and  our  approach  to  a 
solution.  Section  III  makes  useful  distinctions  among  ar¬ 
chitectural  styles,  architecture  schem£is,  and  instcince  circhi- 
tectures,  and  shows  how  they  can  be  represented  as  logical 
theories.  We  use  first-order  theories,  but  our  bcisic  frame¬ 
work  does  not  depend  on  a  particular  logic.  By  formalizing 
architectures  and  their  properties  in  logic,  our  results  can 
be  applied  to  a  large  class  of  architecture  definition  lan¬ 
guages.  Sections  IV,  V,  and  VI  discuss  mappings,  correct¬ 
ness,  and  composition,  respectively. 

Section  VII  presents  several  difierent  refinement  pat¬ 
terns  that  are  used  in  Section  VIII  in  the  development  of 
stcmdard  architectures  for  a  compiler.  The  development 
includes  both  refinement  and  composition.  Sections  IX 
reports  on  a  Icirger  experiment  involving  an  operational 
power-control  system.  Section  X  describes  related  work, 
and  the  last  section  summarizes  our  results,  their  implica¬ 
tions,  and  makes  suggestions  for  future  work. 

II.  Illustration  of  Approach  to  Refinement 

A  software  architecture  is  represented  using  the  following 
concepts. 

1.  Component:  An  object  with  independent  existence, 
e.g.,  a  module,  process,  procedure,  or  variable. 

2.  Interface:  A  typed  object  that  denotes  a  logical 
point  of  interaction  between  a  component  and  its  en¬ 
vironment. 

3.  Connector:  A  typed  object  relating  interface  points, 
components,  or  both. 

4.  Configuration:  A  collection  of  constraints  that  wire 
objects  into  a  specific  architecture. 

5.  Mapping:  A  relation  that  defines  a  syntactical  trans¬ 
lation  from  the  language  of  an  abstract  architecture  to 
the  language  of  a  concrete  architecture. 

6.  Architectiural  style:  For  the  purposes  of  this  pa¬ 
per,  a  style  consists  of  a  vocabulary  of  design  elements, 
well-formedness  constraints  that  determine  how  they 
can  be  used,  and  a  semantic  definition  of  the  connec¬ 
tors  associated  with  the  style. 

Components,  interf^lces,  and  connectors  are  treated  as  first- 
class  objects  —  i.e.,  they  have  a  name  and  they  me  refine- 
able.  Abstract  architectural  objects  can  be  decomposed, 
aggregated,  or  eliminated  in  a  concrete  architecture.  The 
semantics  of  components  is  not  considered  part  of  an  ar¬ 
chitecture,  but  the  semantics  of  connectors  is. 

Consider  the  standard  dataflow  mchitecture  for  a  com¬ 
piler  that  is  depicted  at  the  top  of  Figure  1.  The  diagram 
is  intended  to  convey  an  intuitive  feel  for  the  architecture; 
it  is  not  a  formal  description  of  the  architecture.  Boxes 
denote  functional  components  smd  arrows  denote  direc- 
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Fig.  1.  Two  architectures  for  a  compiler 

tional  dataflow  between  ports.  The  labels  on  arrows  denote 
types  or  value  domains.  A  value  cannot  be  transmitted  be- 
tween  ports  unless  its  type  is  compatible  with  the  types  of 
the  ports.  By  the  completeness  assumption,  this  dataflow 
model  of  the  compiler  fixes  its  functional  units,  their  inter¬ 
faces,  and  the  direction,  source,  and  destination  of  all  of  its 
flows. 

A  textual  specification  of  the  dataflow  architecture  is 
contained  in  Figure  2.  A  dataflow  component  is  a  function 
with  a  signature  describing  its  interface.  Four  dataflow 
connectors  are  declared  to  carry  values  of  various  types. 
The  configuration  assertions  wire  the  connectors  and  inter¬ 
faces  together  into  a  specific  type-consistent  architecture. 
The  module  imports  various  types  and  the  functional  and 
dataflow  styles  for  use  in  the  specification  of  the  architec¬ 
ture. 

A  concrete  architecture  intended  to  implement  the 
dataflow  model  of  the  compiler  is  depicted  at  the  bottom 
of  Figure  1.  The  concrete  architecture  is  a  hybrid  that  im¬ 
plements  the  dataflow  style  in  terms  of  pipe-filter,  batch- 
sequential,  and  shared-memory  styles.  Abstract  signatures 
have  been  changed,  dataflow  connectors  have  been  imple¬ 
mented  in  several  ways,  new  components  (data  objects) 
are  introduced,  and  precedence  relations  are  added  to  pre¬ 
serve  the  original  flows  in  the  presence  of  shared-memory 
communication.^  A  textual  specification  of  the  level-2  ar¬ 
chitecture  of  the  compiler  can  be  found  in  the  appendix. 

We  do  not  want  to  construct  the  level- 1  and  the  level-2 
architectures  and  then  perform  an  after-the-fact  correct¬ 
ness  proof.  Instead,  we  want  to  systematically  and  incre¬ 
mentally  transform  the  level-1  architecture  into  the  level-2 
architecture.  The  level-2  architecture  should  be  correct  by 
construction,  requiring  no  explicit  proofs  in  its  derivation. 
This  can  be  accomplished  through  a  series  of  small,  lo¬ 
cal  refinements,  eadi  of  which  involves  the  application  of 
a  correct  refinement  pattern.  Then,  the  local  refinements 
are  combined  to  form  the  larger  composite  level-2  architec¬ 
ture,  which  is  guaranteed  to  correctly  implement  the  level-1 

*A  dataflow  connection  is  treated  as  an  intransitive  relation. 


coapilar.Ll :  MODULE 

Echar.iport:  SEQ(character)  ->  eode.oport:  code] 
IMPORT  character,  code,  token,  binding,  ast 
FROM  conpiler.types 
IMPORT  Function  FROM  Fnnctional.Style 
IMPORT  Datallou.Channel,  Connects 
FROM  Datallou.Style 
COMPONENTS 

lexical.analyzer:  Function 

[char.iport:  SEQ(character) 

->  token.oport:  SEQ (token), 
bind.oport:  SEQ(binding)] 
parser:  Function 

[token.iport :  SEQ (token) 

->  base.ast.oport:  ast] 
analyzar_optiBizer:  Function 

[base.ast.iport:  ast,  bind.iport:  SEQ(binding) 

->  full.ast.oport:  ast] 
code.generator:  Function 

[fnll.ast.iport:  ast  ->  eode.oport:  code] 
CONNECTORS 

token.channel :  Datailov.Channel [SEQ (token)] 

bind.ehannel :  Dataf lov.Channel [SEQ (binding)] 

base.ast. channel:  Dataf lov.Channel [ast] 
full.ast. channel :  Dataf lov.Channel [ast] 
CONFIGDRRTION 
token.flov: 

Connects (token.channel,  token. oport,  token.iport) 
bind.flov: 

Connects (bind.ehannel,  bind.oport,  bind.iport) 
base.ast .flov: 

Connects (base.ast. channel , 

base.ast.oport,  base.ast. iport) 
full.ast .flov: 

Connects (full.ast. channel , 

full.ast.oport,  full.ast. iport) 

END  coBpilsr.Ll 


Fig.  2.  Specifleation  of  dataflow  architecture  for  the  compiler 


architecture. 

As  an  illustration  of  our  approach,  consider  the  imple¬ 
mentation  of  the  dataflow  channel  between  the  parser  and 
analyzer  in  terms  of  the  reading  and  writing  of  a  shared  ab¬ 
stract  syntax  tree.  More  specifically,  we  propose  to  refine 
abstract  subeirchitecture 

parser:  Function  [  ->  base.ast.oport:  ast] 

analyzer. optimizer:  Function  [base.ast. iport :  ast  ->  ] 
base.ast. channel:  Dataf lov.Channel [ast] 

base.ast. flov: 

Connect s (base.ast .channel , 

base.ast.oport,  base. ast. iport) 

into  concrete  subsirchitecture 

parser:  Function[  ] 

analyzer. optimizer:  Function [  ->  ] 

abstract. syntaz.tree:  Variable [ast] 

vrite.base.ast :  Writes (parser,  abstract .syntaz.tree) 

read.base.ast : 

Reads (analyzer .optimizer,  abstract. syntaz.tree) 

For  simplicity,  the  component  signatures  contain  only 
the  ports  that  are  relevant  to  this  refinement.  The  dataflow 
connection  is  implemented  by  a  component  (a  shared  vari¬ 
able  containing  the  tree)  and  two  connections  (the  read 
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Pattern  of  Abstract  Architecture: 

M:  MODULE  [  ->  ] 

COMPONENTS 

fi:  Functional-Style! Function [  ->  op: t] 
f2'-  Functionnl.Stylo!Function[ip:  t  ->  ] 
CONNECTORS 

c:  Datallou-Style !  Dataflow-Channel  [t] 
CONFIGURATION 

_ a;  Dataflow-Style!Connects(e,  op,  »p) _ 

Pattern  of  Concrete  Architecture? 

M:  MODULE  [  ->  ] 

COMPONENTS 

/i:  Functional-Style iFunctionC  ->  ] 
fji  Functional-Style!Function[  ->  ] 
m :  Shared-Hemory-Style !  Variable  [t] 
CONFIGURATION 

ai :  Shared-Nenory.Style!Vritea(/i,m) 

02 :  Shared-Menory-Style  [Reads  (/2 ,  m) _ 

Abstract  to  Concrete  Associations: 
op  — >  c  — >  m  a  — >  (01,02) 

ip  —> 


Fig.  3.  Simple  refinement  pattern 


and  write  relations).^  The  new  concrete  signature  for  the 
parser  and  the  analyzer  reflects  the  difference  between  port- 
to-port  communication  and  direct  shared-memory  commu¬ 
nication  through  a  variable.  As  an  analogous  example, 
consider  an  architecture  consisting  of  two  procedures  that 
communicate  solely  by  means  of  procedure  calls.  If  we  op¬ 
timize  this  architecture  so  that  large  objects  are  no  longer 
transmitted  by  value,  but  instead  are  accessed  directly  as 
shared  objects,  the  signatures  of  the  two  procedures  would 
change. 

The  refinement  pattern  in  Figure  3  specifies  a  way  to 
implement  dataflow  in  terms  of  the  reading  and  writing  of  a 
single  variable.  The  read  and  write  relations  in  the  concrete 
schema  are  primitives  that  CEinnot  be  refined.  The  italic 
letters  denote  schema  variables  that  can  be  instantiated 
with  object  names,  and  the  symbol  “ !  ”  is  used  to  qualify 
names.  The  pattern  can  be  proven  correct  with  respect  to 
the  four  associations  shown  at  the  bottom  of  the  pattern.^ 
The  abstract  schema  in  the  pattern  matches  the  level- 
1  subarchitecture.  However,  if  the  same  substitutions  are 
made  in  the  concrete  schema,  three  schema  variables  are 
left  uninstantiated  —  namely,  m,  oi,  and  03.  Of  course, 
any  unused  names  could  be  substituted.  Let  us  assume 
that  the  architect  selects  mnemonic  names  that  give  the 
following  associations. 

base-Ast-oport  — > 
basa-ASt-iport  — > 

base-aat-chaimel  — >  abstract.ayntax-trae 
base-aat-flov  — >  (write-baae.ast ,  raad-basa-ast) 


*The  shared  abstract  syntax  tree  could  have  been  represented  as 
an  encapsulated  data  type.  If  we  had  chosen  that  representation, 
the  architecture  would  involve  calls  to  access  functions  that  read  and 
write  the  internal  variable  used  to  represent  the  tree. 

^In  a  correctness  proof,  the  associations  in  the  pattern  are  incorpo¬ 
rated  into  a  more  complex  mapping  between  the  first-order  theories 
that  represent  the  abstract  and  concrete  architectures. 


Since  this  instance  of  the  pattern  matches  the  abstract  sub¬ 
architecture  of  the  compiler  and  since  all  instances  of  the 
pattern  are  guaranteed  to  preserve  correctness,  we  can  con¬ 
clude  that  the  proposed  refinement  is  correct. 

In  a  later  section,  we  define  enough  patterns  to  trimsform 
the  full  level- 1  compiler  architecture  into  the  full  level- 
2  architecture.  Additional  patterns  are  defined  that  can 
be  used  to  transform  the  level-2  architecture  into  a  more 
eflBcient  batch-sequential  architecture.  The  final  batch- 
sequential  architecture  can  be  found  in  the  appendix.  The 
completed  compiler  architecture  can  be  connected  to  other 
subsystem  Mchitectures,  such  as  the  file  system  eirchitec- 
ture,  to  form  a  correct  composite  system. 

III.  Architectures  as  Theories 

We  want  to  leave  open  the  choice  of  language  for  spec¬ 
ifying  an  architecture.  Therefore,  we  will  represent  archi¬ 
tectures  as  logical  theories.  We  find  it  convenient  to  use 
first-order  theories;  however,  our  results  do  not  depend  on 
this  choice. 

It  is  useful  to  distinguish  among  three  related  architec¬ 
tural  theories: 

•  An  architectural  style  is  a  theory  consisting  of  a  vocab¬ 
ulary  of  the  relevant  architectural  concepts  and  well- 
formedness  axioms  that  determine  how  they  can  be 
used.  Also  associated  with  a  style  are  rules  for  trans¬ 
lating  textual  specifications  in  the  style  into  their  un¬ 
derlying  logical  representation. 

•  An  architecture  is  a  theory  consisting  of  one  or  more 
style  subtheories  and  possibly  an  infinite  number  of 
constants  that  etre  names  of  the  objects  in  the  particu¬ 
lar  architecture.  The  axioms  of  the  theory  are  the  style 
Etxioms  and  possibly  additional  axioms  that  relate  the 
constEints. 

•  An  architecture  schema  is  an  architecture  containing 
one  or  more  schema  variables.  An  instance  of  an  ar¬ 
chitecture  schema  is  obtained  by  substitution  of  con- 
steints  for  eill  of  its  schema  variables.  An  instance  of 
an  Eirchitecture  schema  is  sometimes  called  an  instance 
architecture  or  im  instance  theory. 

A.  Architectural  Styles 

Consider  the  datafiow  style.  Its  vocabulary  contains 
predicates  for  describing  functional  components,  ports,  val¬ 
ues  associated  with  ports,  dateiflow  channels,  values  associ¬ 
ated  with  dataflow  channels,  and  connections  of  channels  to 
ports.  More  precisely,  the  following  sorts  denote  the  first- 
cIeiss  objects  in  a  dataflow  theory:  channel,  function,  iport, 
and  oport.  We  also  make  use  of  sorts  bool  and  val,  where 
val  denotes  the  set  of  all  possible  values.  The  dataflow  style 
has  the  following  operations. 

OutPort:  oport  x  function  -+  bool 
Supplies:  oport  x  val  — ►  bool 
InPort:  iport  x  function  — »  bool 
Accepts:  iport  x  val  -+  bool 
Carries:  channel  x  val  — ♦  bool 
Connects:  channel  x  oport  x  iport  —*  bool 
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These  predicates  cire  used  to  represent  a  dataflow  architec¬ 
ture  in  ordinary  first-order  logic.  Sorts  cein  be  represented 
as  unary  predicates  but,  for  simplicity,  we  omit  them  in 
formulas. 

An  example  of  a  well-formedness  axiom  is  that  every 
function  must  have  at  least  one  port: 

Vx3y[InPort(y,  x)  V  OutPort(y,  x)] 

Another  requirement  is  that  a  channel  attached  to  an  out¬ 
put  port  must  be  able  to  carry  any  value  supplied  by  the 
port: 


VxVy[3z  Connects(x,  y,  z) 

D  Vv[Supplies(y,  v)  D  Carries(x,  v)]] 

B.  Translation  to  Logic 

Architectures  and  refinement  patterns  are  expressed  in  a 
readable  textual  language.  To  reason  about  them,  they  are 
translated  into  logic  by  means  of  simple  “theory  generation 
rules”  which  are  associated  with  architectural  styles.  For 
the  dataflow  style,  if  the  specification  of  cin  architecture 
contains  an  instance  of  function  declaration  schema 

/;  Functional^tyle! Function [  ->  op:  t] 

the  underlying  theory  contains  the  same  instance  of  first- 
order  sentences 

OutPort(op,/) 

Vv[Supplies(op,  v)  D  t(v)] 

Similarly,  a  function  declaration  of  the  form 

/:  Fimctional^tylelFimctionCtp:  t  ->  ] 
is  translated  to  axioms 

InPort(»p,/) 

Vv[t(v)  D  Accepts(fp,  v)] 

Dataflow  connector 

c:  Dataf low^tyle ! Dataf lowj;;;bannel  [f] 
translates  to 

Vv[f(v)  D  Carries(c,  v)] 
and  configuration  constraint 

a:  Dataflow^tyle! Connects (c,  op,  ip) 
to 


Connects(c,  op,  ip) 

which  is  not  an  object  and,  therefore,  is  not  named  in  the 
logic. 


C.  Architecture  Schemas 

The  two  schemas  appearing  in  the  pattern  of  Figure  3 
will  be  referred  to  throughout  the  paper.  Theory  0o  corre¬ 
sponds  to  the  abstract  schema  and  theory  ©«  corresponds 
to  the  concrete  schema. 

Theory  6o  is  formed  by  applying  the  theory  generation 
rules  of  the  dataflow  style  to  the  abstract  schema,  which 
gives 


OutPort(op,/i) 

Vv[Supplies(op,v)  D  t(v)] 

InJ’ort(ip,/2) 

Vv[t(v)  D  Accepts(»p,  v)] 

Vv[t(v)  D  Ceirries(c,  v)] 

Connects(c,  op,  ip) 

This  theory  satisfies  the  two  well-formedness  axioms  stated 
earlier. 

The  concrete  architecture  schema  in  Figure  3  is  written 
in  a  shared-memory  style,  which  permits  the  reading  and 
writing  of  a  shared  variable.  Shared- variable  communica¬ 
tion  is  modeled  using  a  call  site  as  the  interface  between 
a  function  and  the  shared  variable.^  A  Ccill  site  serves  the 
same  purpose  as  a  port  in  the  dataflow  style.  The  name 
of  every  different  call  site  must  be  unique.  ©«  has  the 
following  style-specific  sorts:  variable  denotes  the  set  of  all 
possible  variables  eind  site  denotes  the  set  of  all  possible  CeJl 
sites  of  which  there  are  two  kinds.  The  sort  rsite  denotes 
the  sites  that  read,  or  input,  values;  the  sort  wsite  denotes 
the  ones  the  write,  or  output,  values.  The  signature  for  0m 
is 

Holds:  variable  x  val  -♦  bool 
CallSiteOf:  site  x  function  bool 
Writes:  wsite  x  variable  — >  bool 
Puts:  wsite  x  val  — »  bool 
Reads:  rsite  x  variable  — *  bool 
Gets:  rsite  x  val  -♦  bool 

The  axioms  of  ©«  are 

Vv[t(v)  D  Holds(m,v)] 

CaJlSiteOf(u;,/i) 

Writes(u;,  m) 

Vv[Puts(u;,v)  D  t(v)] 

CaIlSiteOf(r,/2) 

Reads(r,  m) 

Vv[t(v)  D  Gets(r,v)] 

which  must  satisfy  the  well-formedness  axioms  for  the 
shared-memory  style.  Schema  variables  r  and  w  denote 
names  of  call  sites  and  do  not  appear  in  Figure  3. 

IV.  Mappings 

To  prove  the  relative  correctness  of  two  architectures,  we 
must  specify  a  mapping  between  them.  An  interpretation 
mapping  is  an  association  between  formulas  of  the  language 
of  the  abstract  theory  and  formulas  of  the  language  of  the 
concrete  theory.  An  interpretation  mapping  is  determined 
using  two  different  mappings. 

•  A  name  mapping  associates  the  objects  declared  in  an 
abstract  Mchitecture  with  objects  declared  in  a  con¬ 
crete  architecture. 

•  A  style  mapping  says  how  the  constructs  of  an 
abstract-level  style  can  be  implemented  in  terms  of  the 
constructs  of  a  concrete-level  style.  More  specifically, 

^We  could  have  chosen  not  to  model  call  sites  or  some  equivalent 
interface  object,  but  this  would  require  a  more  liberal  definition  of 
interpretation  than  the  one  given  in  this  paper.  The  present  model 
simplifies  the  mapping  from  &d  to  6m. 
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it  maps  uninstantiated  predicates  of  the  abstract-level 
language  to  uninstantiated  formulas  of  the  concrete- 
level  language. 

Style  mappings  can  be  complicated,  but  need  to  be  defined 
and  proved  only  once.  Name  mappings  are  much  simpler 
and  are  specific  to  a  given  pair  of  architectures. 

A  name  mapping  is  determined  by  the  identifier  associa¬ 
tions  in  a  given  refinement  pattern.  For  example,  associa¬ 
tion  c — >m  in  Figure  3  says  that  channel  c  of  the  abstract 
schema  is  mapped  to  variable  m  of  the  concrete  schema. 
Association  op  — >  says  that  the  concrete  object  that  cor¬ 
responds  to  abstract  port  op  is  not  explicitly  named  in  the 
concrete  schema.  Since  we  have  chosen  a  shared-memory 
model  that  has  call  sites  corresponding  to  ports,  we  are  free 
to  introduce  any  unused  name  for  the  sites. 

Let  N°  be  name  mapping 

c  y-*  m 
op  >-*  w 
tp  r 

which  relates  objects  in  0d  to  their  refinements  in  0m-  Ob¬ 
serve  that  not  every  association  in  the  refinement  pattern 
appears  in  the  name  mapping.  Identifiers  a,  ai ,  and  02  refer 
to  part  of  the  specification  but  do  not  name  objects.  Hence, 
they  do  not  appear  in  the  logical  representation.  The  do¬ 
main  of  a  name  mapping  can  be  extended  to  include  all 
abstract-level  terms  by  mapping  variables  to  themselves.® 

Let  denote  the  general  mapping  from  the  dataflow 
style  to  the  shared-memory  style: 

Function(^i)  i-*  Function( — 1) 

OutPort( — 1,  — ^2) 

!-♦  CallSiteOf( — 1,  —2)  A  3v  Puts( — 1,  v) 
Supplies( — 1,  — ^2)  •->  Puts( — 1,  — ^2) 

InPort( — 1,  — 2) 

CallSiteOf( 1,  — ^2)  A  3v  Gets( — 1,  v) 

Accepts( 1,  — 2)  Gets( — 1,  — ^2) 

Channel  ( 1)  Variable  ( — 1) 

Carries( 1,  — 2)  Holds( — 1,  — ^2) 

Connects( _ 1,  — 2,  — 3) 

i-»  Writes( — 2,  — 1)  A  Reads( — 3,  — 1) 

The  Puts  cmd  Gets  predicates  ensure  that  the  right  kind  of 
site  is  eissociated  with  each  port. 

The  last  association  specifies  the  implementation  strat¬ 
egy.  In  0D  we  have  Connects(c,  op,  ip),  which  can  be  imple¬ 
mented  by  having  the  call  that  corresponds  to  op  perform  a 
write  operation  on  the  variable  that  corresponds  to  channel 
c,  and  the  one  that  corresponds  to  ip  read  the  variable  that 
corresponds  to  c.  The  other  associations  say  that  channels 
are  mapped  to  variables,  that  output  ports  are  mapped  to 
calls  that  supply  values,  and  that  input  ports  are  mapped 
to  cedis  that  receive  values. 

An  interpretation  mapping  I  is  determined  from  a  neime 
mapping  N  and  a  style  mapping  S,  as  follows:  for  every 

®Note  that  our  languages  contain  no  function  symbols.  A  formal 
treatment  of  interpretations  for  languages  that  include  them  can  be 
found  in  [6]. 


predicate  P,  all  terms  ti,t2,..-,t„,  every  variable  x,  and 
all  formulcis  F  and  G  of  the  abstract  language. 


I{P{ti,t2,  ■  ■  •  ,tn))  — 

/(-.F)  = 
/(FAG)  = 
7(FVG)  = 
I{FdG)  = 
J(VxF)  = 
/(3xF)  = 


S(P){N{h),Nit2) . JV(t„)) 

■^im) 

/(F)  A /(G) 

/(F)  V  /(G) 

/(F)  D  /(G) 

Vx/(F)® 

3x/(F) 


Let  denote  the  interpretation  mapping  firom  theory 
0o  to  theory  0m.  Both  the  basic  facts  and  the  general  well- 
formedness  axioms  in  0d  must  be  mapped.  For  example, 

/j5(Connects(c,  op,  ip)) 

=  (Connects)  (Ar“  {c),N°{op),N°{ip)) 

=  (Connects)  (m,  w,  r) 

=  Writes(ti;,  m)  A  Reads(r,  m) 

which  is  the  intended  implementation.  Similarly,  the  gen¬ 
eral  dataflow-style  requirement  that  each  function  have  at 
least  one  input  or  output  port  maps  to  the  shared-memory 
requirement  that  each  functiori  have  a  C2J1  site  that  can 
input  or  output  values.  That  is, 

/S(Vx3y[InPort(y,x)  V  OutPort(y,x)]) 

=  Vx3y[/S(InPort(y,x))  V  /S(OutPort(y,x))] 

=  Vx3y[5S(InPort)(Arj5(y),  N5(x)) 

VS-(OutPort)(NlS(y),NS(x))] 

=  Vx3y[(CallSiteOf(y,x)  A  3v  Gets(y,  v)) 

V  (CallSiteOf(y,x)  A  3v  Puts(y,  v))] 


V.  Correctness 


Two  instemce  architectures,  represented  as  theories,  are 
proven  correct  with  respect  to  an  interpretation  mapping 
between  them  and  the  completeness  eissumption.  An  inter¬ 
pretation  mapping  contains  a  style  mapping  whose  seman¬ 
tic  correctness  should  be  established  as  a  proof  obligation. 
Proof  of  style  mappings  is  discussed  in  a  companion  paper 
[18],  which  gives  a  proof  of  mapping  5^  from  the  dataflow 
to  the  shared-memory  style.  The  connectors  in  the  styles 
are  deflned  in  a  tempered  logic,  eind  both  safety  and  fairness 
conditions  are  shown  to  be  satisfied  by  the  shared-memory 
implementation.  The  safety  condition  is  that  the  shared- 
memory  implementation  preserves  order  and  does  not  lose 
values;  the  fairness  condition  is  that  all  values  written  into 
shared  memory  will  eventually  be  read.  The  proof  of  a  style 
mapping  is  performed  only  once;  it  need  not  be  repeated 
when  the  two  styles  axe  used. 


A.  Criterion 

Let  0  and  0'  be  instance  theories  (containing  no  schema 
variables)  associated  with  an  abstract  and  a  concrete  archi¬ 
tecture,  respectively.  Let  /  be  an  interpretation  mapping 

^In  general,  the  range  of  quantifiers  must  be  restricted  to  a  subset 
of  the  concrete  domain,  see  [6].  But  no  restriction  is  required  for  our 
example,  because  every  concrete-level  object  implements  an  abstract- 
level  object. 
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from  the  language  of  &  to  the  language  of  For  every 
sentence  F,  mapping  7  is  a  theory  interpretation  provided 

if  F  €  0  then  1(F)  6  &' 

This  is  the  usual  definition  of  correctness. 

Since  a  given  architecture  is  assumed  to  be  complete  with 
respect  to  its  level  of  detcdl,  we  additionally  require  that  the 
concrete  architecture  add  no  new  facts  about  the  abstract 
eirchitecture.  To  prove  this,  we  must  additionally  show  that 

it  F^G  then  /(F)  & 

in  which  case  7  is  a  faithful  interpretation.  This  says  that, 
if  a  sentence  is  not  in  the  abstract  theory,  its  image  cannot 
be  in  the  concrete  theory.  Observe  that  &'  is  a  conser¬ 
vative  extension  of  &  provided  the  identity  map  faithfully 
interprets  0  in  0'. 

B.  Proof  Technique 

Agciin,  let  0  and  0'  be  instance  theories  and  7  be  the  in¬ 
terpretation  mapping  between  them.  We  present  a  general 
model-theoretic  proof  technique  for  showing  that  interpre¬ 
tation  mapping  7  is  a  fedthful  interpretation  of  abstract 
theory  0  in  concrete  theory  0'.  First,  we  prove  that  7  is 
a  theory  interpretation  of  0  in  0'.  This  can  be  done  by 
means  of  a  standard  proof  technique:  For  every  axiom  in 
0,  establish  that  the  image  of  the  axiom  under  I  is  a  logical 
consequence  of  the  axioms  of&'. 

Second,  we  must  prove  that  interpretation  mapping  7  is 
a  faithful.  The  proof  method  has  to  take  into  account  that 
there  is  no  direct  method  for  determining  that  a  formula  is 
not  in  0'.  Our  proof  technique  for  faithfulness  is  based  on 
two  model-theoretic  concepts: 

•  The  interpretation  mapping  7  from  0  to  0'  induces  a 
mapping  7'  from  structures  of  the  concrete  language  to 
structures  of  the  abstract  language.'^  Given  a  structure 
A'  of  the  concrete  language,  7'  maps  A'  to  a  structure 
A  of  the  abstract  language  as  follows.  The  universe  of 
A  is  the  same  as  the  universe  ot  A'.  It  I  maps  atomic 
formula  P{xi,X2,  ■■■,  Xn)  to  concrete  formula  F,  then 
7'  assigns  to  predicate  P  in  the  abstract  language  the 
set  of  tuples  in  A'  that  satisfy  F. 

•  The  theory  that  describes  structure  A  is  obtained  as 
follows.  First,  expand  the  Icmguage  of  A  to  include  a 
name  for  every  member  of  the  universe  of  A.  Next, 
expand  A  by  assigning  every  new  name  to  the  appro¬ 
priate  member  of  A.  The  theory  that  describes  A  is 
the  set  of  sentences  in  the  expanded  language  that  are 
true  in  the  expemded  structure. 

Our  technique  for  proving  the  friithfulness  of  7  can  now 
be  stated  as  follows:  For  every  model  A  of  0,  find  a  model 
A'  of  0'  such  that  the  image  of  A'  under  the  induced  map¬ 
ping  r  can  be  expanded  to  a  model  of  the  theory  that  de¬ 
scribes  A.  This  model-theoretic  characterization  of  faith¬ 
fulness  is  equivalent  to  our  theory-based  definition  of  cor¬ 
rectness. 

^Recall  from  logic  that  a  structure  of  a  first-order  language  consists 
of  a  universe  and  the  assignment  of  elements  of  the  universe  to  the 
constants  and  relations  over  the  universe  to  the  function  and  predicate 
symbols. 


Roughly  speaking,  this  characterization  requires  that,  for 
every  model  A  of  0,  there  is  a  model  A'  of  0'  such  that  A 
and  P(AI)  cannot  be  distinguished  using  the  resources  of 
first-order  logic.  If  we  were  to  use  an  architectural  specifi¬ 
cation  language  based  on  some  other  logic,  a  similar  char¬ 
acterization  based  on  the  expressive  power  of  that  logic 
would  be  substituted.  For  excimple,  if  the  content  of  our 
architectural  specifications  were  expressed  in  type  theory, 
we  would  require  that  I'(A!)  can  be  expanded  to  model 
every  type-theoretic  sentence  expressible  in  the  language 
that  contains  a  name  for  every  object  in  the  domain  of  A, 
every  relation  among  those  objects,  every  relation  among 
those  relations,  and  so  on,  that  is  true  in  A.  (It  is  eEisy 
to  see  that  this  amounts  to  requiring  that  7'(.4')  and  A 
be  isomorphic.)  So  our  general  method  for  demonstrating 
faithfulness  can  be  used  with  any  logic-based  architectural 
specification  lemguage,  as  long  as  the  question  of  whether 
a  structure  that  represents  an  architecture  satisfies  a  spec¬ 
ification  heis  a  well-defined  answer. 

C.  Application  to  Refinement  Patterns 

A  refinement  pattern  consists  of  a  triple  (0, 0',  N)  where 
0  and  0'  are  theories  containing  schema  variables  and  N 
is  a  name  mapping  from  0  to  0'.  A  pattern  is  correct 
provided  every  instance  of  0  cmd  0'  is  relatively  correct 
with  respect  to  the  same  instance  of  interpretation  mapping 
7  :  0  — >  0'  determined  by  mapping  N  and  the  relevant 
style  mapping(s). 

Consider  theories  0d  and  0m  related  by  interpretation 
mapping  I^.  We  must  show  that,  for  every  instantiation  of 
the  schema  variables,  is  a  theory  interpretation  of  0d 
in  0M  and  7^  is  faithful.  The  former  is  straightforward. 

To  prove  faithfulness,  consider  the  induced  mapping  of 
I^.  It  M  is  a  structure  for  0',  then  the  induced  mapping 
applied  to  Ad  is  a  structure  V  for  the  dataflow  language. 
The  only  interesting  assignment  is  to  the  predicate  Con¬ 
nects,  which  is  the  set  of  tuples 

{(x,y,z)  6  f=  Writes(i/,x)  AReads(z,x)} 

because  maps  Connects(c,  op,  ip)  to  the  formula 

Writes(u;,  m)  A  Reads(r,  m) 

where  c,  op,  ip,  w,  m,  ^md  r  are  schema  variables. 

To  show  that  is  faithful,  we  use  7^  to  transform  a 
model  I?  of  an  instance  of  0d  to  a  model  Ad  of  an  instance 
of  0M.  The  universe  of  Ad  is  the  same  as  D  in  this  example. 
The  predicate  Function  is  assigned  to  the  set  of  all  objects 
that  are  functions  in  27,  namely, 

{x  g  |2?|:27  )=  Function(x)} 

so  that  2?  and  Ad  agree  on  functions.  The  predicate  Vari¬ 
able  is  assigned  to 

{x  €  |2)|:27  |=  Channel(x)}, 
the  predicate  Reads  is  assigned  to 
{(^iJ/)  G  |2?p:for  some  z  in  |2>|,  27  ^  Connects(j/,z,x)} 
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and  similarly  for  the  remaining  predicates.  The  image  of 
M  under  the  induced  mapping  is  V.  Obviously,  V  can 
be  expanded  to  a  model  of  the  theory  that  describes  V. 
Therefore,  is  faithful.  Note  that,  since  the  image  of  M 
under  the  induced  mapping  is  identical  to  V,  the  interpre¬ 
tation  would  remain  faithful  if  we  were  to  switch  from 
first-order  logic  to  some  stronger  logic,  such  as  type  theory. 

VI.  Composition 

We  define  two  forms  of  composition  for  instance  architec¬ 
tures.  Horizontal  composition  is  used  to  compose  instcinces 
of  refinement  patterns  to  form  one  large  composite  refine¬ 
ment  architecture.  It  is  also  used  to  compose  existing  archi¬ 
tectures  into  larger  architectures.  Vertical  composition  is 
used  to  chain  together  a  sequence  of  correct  architectures, 
allowing  us  to  conclude  that  the  most  concrete  architecture 
in  a  hierarchy  is  correct  with  respect  to  the  most  abstract 
architecture  in  the  hiercirchy.  Vertical  composition  is  justi¬ 
fied  since  faithful  interpretation  is  transitive. 

Let  01  and  02  be  instance  theories  that  represent  two 
abstract  architectures.  Let  0'i  and  02  be  concrete  theories 
intended  to  implement  0i  and  02,  respectively.  Two  pairs 
of  architecture  theories  can  be  composed  only  in  ways  that 
preserve  faithfulness.  More  precisely,  if 

h'  ©1  and  I2:  02  &2 

are  faithful  interpretations,  then  we  want 
Ii  U I2:  01  U  02  -*  01  U  02 

to  be  a  faithful  interpretation.  (The  union  of  two  theories 
is  the  deductive  closure  of  the  set-theoretic  union  of  the 
theories.) 

This  property  holds  provided  two  general  conditions  are 
satisfied. 

1.  The  composite  interpretation  mapping  must  be  a 
function.  For  a  sentence  F,  we  require  that 

if  F€0ir\02  then  Ii{F)  =  12(F) 

which  guarantees  that  interpretation  mappings  /j  and 
I2  agree  on  shared  objects  and  shared  style  constructs. 

2.  It  must  not  be  possible  to  infer  new  facts  about  the 
composite  abstract  architecture  from  the  composite 
concrete  architecture.  That  is,  for  language  Li  of  0i 
and  L2  of  02,  if 

f  is  a  sentence  of  Li  U  L2 

and 

0'iU0'2  h  /lU  72(F) 

then  we  must  prove  that 

7i[6»i]U  72(02]  b  7iU  72(F). 

The  intuition  behind  the  second  condition  can  be  illus¬ 
trated  by  means  of  a  simple  example.  Consider  an  ar¬ 
chitecture  in  which  there  is  a  dataflow  connection  from 


A  to  B  and  another  architecture  that  heis  dataflow  con¬ 
nection  from  B  to  C.  Suppose  that  both  flows  are  im¬ 
plemented  correctly  in  concrete  architectures,  but  that  in 
one  A  writes  some  variable  x  and  in  the  other  C  reads  a 
variable  x.  Each  implementation  is  correct,  since  neither 
introduces  a  new  dataflow.  However,  the  composite  con¬ 
crete  architecture  reads  and  writes  x,  from  which  we  can 
infer  an  entirely  new  abstract  datetflow  connection  from  A 
to  C.  Consequently,  the  composite  abstract  architecture 
is  not  faithfully  interpreted  (by  the  composite  mapping) 
in  the  composite  concrete  architecture  (under  the  original 
eissumption  that  dataflow  is  intransitive). 

Of  course,  we  do  not  want  to  have  to  prove  that  ev¬ 
ery  refinement  pattern  can  be  composed  with  every  other 
refinement  pattern.  Instead,  we  would  like  simple  syntac¬ 
tic  criterionthat,  if  satisfied,  guarantees  compositionality. 
One  such  criterion  is  that  the  two  abstract  architectures 
can  share  only  components  and  lower-level  architectures 
can  share  only  images  of  those  components  under  the  in¬ 
terpretation  mapping.  This  meEins  that  an  architecture 
cannot  contain  certain  global  assertions,  such  as  a  require¬ 
ment  that  there  are  exactly  three  connections  in  ray  archi¬ 
tecture. 

An  example  of  the  horizont£il  composition  of  pattern 
instances  involves  the  compiler  architecture  in  Figure  1. 
We  have  proved  that  the  dataflow  connection  between  the 
parser  and  the  analyzer  is  implemented  correctly  by  means 
of  the  reading  and  writing  of  the  tree,  using  instances  of 
0o,  0Mi  and  from  Figure  3.  Similarly,  we  can  show 
that  the  dataflow  connection  from  the  lexical  analyzer  to 
the  parser  is  correctly  implemented  by  the  pipeline  connec¬ 
tion.  The  two  architectures  share  only  one  component,  the 
pMser.  Therefore,  our  second  condition  is  satisfied  £ind  we 
can  compose  them  without  further  proof. 

A  different  kind  of  example  is  contained  in  Figure  4.  We 
want  to  compose  two  architectures,  called  “subsystem  A” 
and  “subsystem  B",  into  a  single  system  architecture.  We 
construct  a  new  architecture  with  components  “A”  and 
“B”  connected  through  new  interfaces.  According  to  our 
syntactic  constraint,  the  three  eirchitectures  can  be  com¬ 
bined  to  form  a  composite  system  that  is  correct  if  the 
three  subsystems  are. 

VII.  Some  Refinement  Patterns 

We  present  six  broadly  useful  patterns  for  refining  com¬ 
ponents,  connectors,  and  interfaces.®  The  patterns  involve 
several  common  Mchitecture  styles  cind  each  pattern  has 
been  proven  correct. 

A  refinement  pattern  is  presented  in  a  table  contedning 
two  architecture  schemcis,  an  Msociation  of  abstract  and 
concrete  objects,  and  possibly  constraints  on  one  or  both 
of  the  schemas.  By  convention,  a  schema  variable  that  oc¬ 
curs  in  both  an  abstract  and  a  concrete  schema  must  match 
the  same  object,  modulo  renaming.  We  prime  a  concrete 
schema  variable  to  indicate  that  it  is  the  name  of  a  new  ob¬ 
ject  not  associated  with  any  abstract-level  object,  or  that  it 

•Type  refinement  is  not  covered  because  it  requires  a  somewhat 
different  correctness  criterion. 
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Fig.  4.  Illustration  of  Subsystem  Composition 


Symbol 

Style  Name 

BS 

BAteh^aqu«ntial^tyla 

CT 

Control-Tranafar Jtyla 

D 

Dataflov^tyl« 

F 

Functional-Style 

pp 

Proceas-Pipeline-Style 

SM 

SharadJIamory^tyla 

TABLE  I 

Abbreviations  for  style  names  in  refinement  patterns 


denotes  a  required  change  to  the  associated  abstract-level 
object.  The  intended  meaning  is  obvious  from  context.  A 
reference  to  a  style  in  a  refinement  pattern  is  abbreviated 
according  to  the  naming  conventions  summarized  in  Ta¬ 
ble  I. 

We  assume  that  connections  in  an  architecture  do  not 
share  interface  points.  Multiple  uses  of  a  given  interface 
point  cire  modeied  with  multiple  copies  of  the  same  point. 
This  model  has  the  adveintage  that  interfaces  and  connec¬ 
tions  Ccm  be  refined  more  flexibly.  However,  this  choice  of 
representation  Ccm  result  in  an  increeise  in  the  number  of 
interface  points. 

A.  Component  Refinement 

Figure  5  contains  a  refinement  pattern  for  decompos¬ 
ing  a  functional  component  into  a  collection  of  components 
wrapped  by  a  module.  Component  /  is  refined  into  mod¬ 
ule  /',  hence  the  cissociation  / — >/'.  A  module  signature 
contains  all  externally  visible  interfaces  within  the  mod¬ 
ule.  Since  each  interface  point  is  an  object  with  a  unique 
name,  there  is  no  confusion  as  to  the  correspondences  be¬ 
tween  the  interface  points  of  /  and  those  of  components  in 
/'.  By  requiring  that  /  and  /'  have  the  same  signature, 
we  cire  guciranteed  that  the  original  connections  involving 
/  are  maintained  through  its  subcomponents.  The  refine¬ 
ment  is  faithful  because  the  interface  requirement  on  /  and 
/'  prevents  the  addition  or  deletion  of  connections. 

The  next  two  patterns  are  for  aggregating  variables  in 
situations  that  are  common  in  intermediate  stages  of  a  de¬ 
velopment.  This  is  done  for  time  and  space  efficiency,  es- 


Pattern  of  Abstract  ArchitectureT 
M:  MODULE  [pi  -> 

COMPONENTS 

/:  F!Fuiiction[pii  ->  pij] 
Pattern  of  Concrete  ArchitectureT 
M:  MODULE  [pi  ->  P2] 

COMPONENTS 

/':  MODULE  [pii  ->  P12] 
Abstract  to  Concrete  AssociationsT 
/  -->  /' 


Fig.  5.  Decomposing  a  component  into  subcomponents  (Pattern  1) 

pecially  if  the  variables  hold  large  objects.  Application  of 
the  patterns  also  results  in  a  simpler  design. 

Figure  6  contmns  a  pattern  for  merging  shared  variables 
when  one  of  them  is  a  private  variable.  This  pattern  merges 
a  shared  variable  mi ,  which  is  written  by  component  /i  2ind 
read  by  component  /2,  with  a  private  variable  m2,  which 
is  read  and  written  by  component  f\.  This  is  expressed 
by  the  association  (mi, m2) — >m'.  There  are  three  basic 
requirements  on  this  form  of  refinement: 

•  The  variables  denoted  by  schema  viiriables  mi  2md  m2 
must  have  the  same  type,  denoted  by  schema  Vctriable 
t. 

•  Only  the  component  denoted  by  /i  can  write  the  vari¬ 
able  denoted  by  mi.  This  prevents  a  new  flow  to  /i, 
which  would  violate  the  faithfulness  requirement. 

•  Only  /i  accesses  private  variable  m2,  otherwise  a  new 
flow  would  be  created  by  the  refinement.  This  require¬ 
ment  is  enforced  by  the  constraint  on  the  abstract  ar¬ 
chitecture. 

A  variant  of  this  pattern  combines  the  shared  variable 
and  the  private  variable  into  two  fields  of  a  record  struc¬ 
ture.  With  this  vEiriant,  the  constraint  on  the  abstract 
architecture  is  not  needed,  provided  that  the  components 
involved  access  only  the  proper  fields  of  the  record.  This 
kind  of  refinement  would  not  increase  efficiency,  but  could 
help  simplify  the  design. 

Figure  7  contains  a  pattern  for  merging  shared  variables 
when  neither  of  them  are  private.  The  two  shared  vari¬ 
ables  are  connected  by  a  common  functional  component. 
A  shared  variable  denoted  by  schema  variable  mi  is  writ¬ 
ten  by  functional  component  /i  and  read  by  /2.  Shared 
variable  m2  is  written  by  /2  and  read  by  /$.  The  merge  is 
expressed  by  the  association  (mi, m2)  — >m'. 

Our  correctness  criterion  places  the  following  restrictions 
on  the  architectures: 

•  The  variables  to  be  merged  must  be  of  the  same  type 
t. 

•  Since  we  treat  dataflow  as  an  intransitive  relation,  we 
also  treat  other  relations  dealing  with  the  flow  of  data 
as  intransitive  relations.  Therefore,  functioned  compo¬ 
nents  /i,  /2,  and  fs  have  to  be  executed  sequentially 
in  batch  mode  so  that  we  cannot  infer  the  existence  of 
a  new  abstract  flow  from  /i  to  /a.  This  is  prevented 
by  configuration  assertions  05  and  Og. 

•  No  other  functional  components  cem  read  mi  or  write 
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M:  MODULE  [pi  ->  PsJ 
COMPONENTS 

fl  :  F!Function[pii  ->  PX23 
/j  :  FlFunetionCpji  ">  P22] 
mi:  SM !  Variable  [t] 
m2:  SH!  Variable  [t] 

CONFIGURATION 

oi:  SM!Write8(/i,mi) 

02:  SM!Reads(/2,mi) 
as:  SM!Vrites(/i,m2) 

04:  SM!Read8(/i,m2)  _ 


nunRF.TF.  Architecture: 


M:  MODULE  [pi  ->  P2] 

COMPONENTS 

fl  :  F!Fiinction[pii  ->  P12] 

/2  :  F! Function [p2i  ">  P22] 
m':  SM!  Variable  [i] 

CONFIGURATION 

ai:  SM!Write8(/i,m') 
a'j:  SM!Read8(/2,m') 

o^:  SM!Reads(/i,m') _ 

Abstract  to  Concrete  Associations: 

(mi, m2)  — >  (oii^s) 

02  — >  a'2 

(Constraints  on  Abstract  architecture: 
-i(3/:  FlFunction) 

[/  *  fl 

A  [SM!Write8(/,mi) 

V  SH!Nrite8(/,m2) 

V  SMiReadsC/,  ms)]] 


M:  MODULEEpi 

->  P2] 

COMPONENTS 

fl  ' 

FIFunctionEpii  ->  P12J 

h  • 

F! Function [p2i  *>  P22] 

fz  ’ 

F!Function[p3i  ->  P32] 

mi : 

SM!  Variable  [t] 

m2: 

SM!  Variable  [t] 

CONFIGURATION 

ai: 

SMIWrites(/i,mi) 

02: 

SN!Reads(/2,mi) 

03: 

SM!Write8(/2,m2) 

04: 

SM!Read8(/3,m2) 

Pattern  of 
M:  MODULEEpi  ->  P2] 

COMPONENTS 

fl  :  F!Function[pii  ->  P12] 

/s  :  F! Function [p2i  ->  P22] 

/s  :  F!Function[p3i  ->  P32] 
m':  SM!  Variable  [t] 

CONFIGURATION 

a'j:  SM!Write8(/i,m') 
o':  SH!Reads(/2,m') 
at:  SM!Hrites(/2,m') 
o^:  SM!Reads(/3,m') 

o'j :  BS !  Start8_Af  ter  Jinish.Of  C/2 ,  /l ) 
oI, :  BS !  Start  8-Af  ter  Jini8h.0f  C/s .  /2  ) 
Abstract  to  concrete  Associations? 

(mi,  m2)  ">  oi  ">  o'l 


Fig.  6.  Merging  a  shared  variable  with  a  private  variable  (Pattern  2) 

m2,  which  is  enforced  by  a  constraint  on  the  abstract 
architecture. 

A  varicint  of  this  pattern  combines  the  shared  variables 
into  two  fields  of  a  record  structure.  With  this  variant, 
the  sequential  ordering  assertions  in  the  concrete  architec¬ 
ture  and  the  constraint  on  the  abstract  architecture  are  not 
needed. 

B.  Connector  Refinement 

Figure  8  contains  a  pattern  for  implementing  a  datafiow 
connector  by  a  pipe.  Datafiow  channel  c  from  fi  to  /2  is 
refined  into  a  pipe  c'  connecting  fi  to  /2.  The  connec¬ 
tor  refinement  is  expressed  by  the  associations  c  >cf  and 
o— >a'.  This  refinement  is  obviously  faithful.  Semanti¬ 
cally,  it  can  be  justified  on  the  basis  of  the  meaning  of  the 
dataflow  and  pipe  connectors. 

Figure  9  contains  a  pattern  for  refining  two  functional 
components  fi  and  /2  that  are  executed  in  batch-sequential 
mode  into  a  module  with  a  main  functional  component  /' 
transferring  control  first  to  /i  and  then  to  f2-  The  correct¬ 
ness  of  refinements  of  this  form  depends  on  the  following 
properties. 

.  Component  fi  has  to  complete  before  /2  can  start, 
which  is  enforced  by  configuration  assertion  o'. 

.  Concrete  component  /'  cannot  transfer  control  to  /2 
until  fl  completes,  and  fi  cannot  transfer  control  to 
/'  after  fi  starts.  These  ordering  relationships  are 


Donstratnt.'s  on  Abstract  Architecture: 
n(3/:  FlFunction) 

A  [SMIBead8(/,mi) 

V  SM!Writ«8(/,m2)]] 


Fig.  7.  Merging  shared  variables  (Pattern  3) 


Pattern  of  Abstract  Architecture' 

M:  MODULECpi  ->  P2] 

COMPONENTS 

fi:  F! Function [pii  ->  op:l,  P12] 
fi:  F!Function[ip:l,  P21  ">  P22] 
CONNECTORS 

c:  D !  Dataf  lou-Cbannel  [t] 
CONFIGURATION 

o:  D!Connects(c,  op,  tp) 

Pattern  of  Concrete  architectureT 
M:  MODULEEpi  ->  P2] 

COMPONENTS 

fi:  FIFunctionEpii  ->  op’.t,  P12] 
fi'.  F!Function[tp:t,  P21  “>  P22] 
CONNECTORS 

c':  PPlPipeEt] 

CONFIGURATION 

o' :  PP !  Connects  (c' ,  op,  ip) 
Abstract  to  concrete  Associations: 
c  — >  c'  o  — >  o' 


Fig.  8.  Implementing  a  dataflow  connector  by  a  pipe  (Pattern  4) 
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l■iAJ<j:.l;^«.»;^:l■•^.J!H.l.l■;^;l.lill■JJri■lll;^g 


M:  MODDLE[ip:t,  pi  ->  op:t,  P2J 
COMPONENTS 

/i:  FIFunctionlpii  ->  op:t,  P12] 
/2!  F!Funetion[ip; t,  p2i  ->  p223 
CONNECTORS 

c:  D!Dataflow.Chaimel[t] 
CONFIGURATION 

a:  D ! Connects (c,  op,  <p) 


M:  MODULE  [pi  ->  P2] 

COMPONENTS 

/l  :  FiFunctionCpil  ->  P12] 
/2  :  F!Function[p2i  ->  P22] 
m':  SM!  Variable  [t] 
CONFIGURATION 

oi:  SM !  Writes 
'  :  SM!Reads(/2,m') 


SSOCIATIONS: 


C  -->  m'  a  ->  (a'l.oi) 

(op, «p)  — > 


Fig.  9.  Implementing  ordering  constraint  using  explicit  control  trans¬ 
fer  (Pattern  5) 


Fig.  10.  Implementing  dataflow  with  a  shared  variable  (Pattern  6) 

The  development  of  the  level-2  architecture  involves 
three  main  steps  —  the  introduction  of  the  pipe  between 
the  lexical  analyzer  and  the  parser,  the  development  of  the 
shared  tree  accessed  by  the  parser,  analyzer /optimizer,  and 
code  generator,  and  the  development  of  the  shared  symbol 
table  between  the  lexical  analyzer  and  the  optimizer.  All 
patterns,  with  the  exception  of  Pattern  5,  are  used.  (Pat¬ 
tern  5  is  applied  repeatedly  to  the  level-2  compiler  archi¬ 
tecture  to  get  the  level-3  architecture  in  the  appendix.) 


enforced  by  the  two  constraints  on  the  concrete  archi¬ 
tecture. 

•  All  functional  components  have  to  be  enabled  by  /' 
and  every  control  transfer  must  be  between  /'  and 
a  functional  component.  This  is  enforced  by  a  well- 
formedness  constraint  in  the  control-transfer  style,  not 
by  a  constraint  in  the  pattern. 

C.  Interface  Refinement 

Figure  10  contains  the  full  specification  of  the  pattern  in¬ 
troduced  earlier  in  Figure  3.  The  refinement  of  the  dataflow 
connection  into  a  shared-memory  implementation  has  the 
side  effect  of  changing  the  signature  of  the  two  functions, 
since  connections  do  not  share  interface  points. 

VIII.  Example  Revisited 

We  now  apply  the  refinement  patterns  to  the  compiler 
architectures  illustrated  earlier  in  Figure  1.  In  particu¬ 
lar,  we  show  how  the  level-1  compiler  architecture  can  be 
refined  into  the  level-2  compiler  architecture  using  five  of 
the  patterns.  The  textual  specification  of  the  architectures 
are  simplified  through  the  use  of  ellipses  for  parts  of  the 
specification  that  are  not  relevant  to  the  refinement  under 
consideration.  The  full  textual  specifications  for  levels  1 
and  2  axe  in  Figure  2  and  the  appendix,  respectively. 


A.  Introduction  of  the  Pipe 

This  refinement  is  a  straightforward  application  of  Pat¬ 
tern  4.  Consider  the  following  abbreviated  subarchitecture 
of  the  level-1  compiler. 

conpiler.Ll:  NODULE 

[char.iport:  SEQIcbaracter)  ->  code.oport:  code] 
COMPONENTS 

lezical.analpzer :  Function 

[...  ->  tokan.oport;  SEQ (token),  ...] 
parser:  FunctionCtoken.iport:  SEQ(token)  ->  ...] 
CONNECTORS 

token. channel :  Datallov. Channel [SEQCtoken)] 

CONFIGURATION 

token.flov: 

Connects(token_channel,  token.oport,  token.iport) 

Pattern  4  can  be  used  to  refine  dataflow  channel 
token.cheumel  into  pipe  token_pipe,  resulting  in  the  fol¬ 
lowing  level-2  architecture.® 

compiler .L2:  NODULE 

[char.iport:  SEQ (character)  ->  code.oport:  code] 
COMPONENTS 

lezical.analyzer. module:  NODULE 

[...  ->  token.oport:  Finite.Stream(token)] 
parser:  Function 

[token.iport:  Finite.Strean(token)  ->  ] 

®Aii  output  and  an  input  port  of  type  SEQ(token)  were  implemented 
as  type  Finite.Strean(token).  A  stream  is  a  function  from  clock 
times  to  values.  The  correctness  of  this  type  refinement  is  not  treated 
in  this  paper. 
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CONNECTORS 

tokan.pipe ;  Pips  [Finita.StraaiiCtokan)  ] 

CONFIGDRITION 

tokan.flow: 

Coimacts(tokan_pipa,  tokan.oport,  token.iport) 

B.  Development  of  the  Shared  Abstract  Syntax  Tree 
Consider  the  following  dataflow  architecture. 

coapilar.Ll :  MODULE 

[char.iport:  SEQCcharactar)  ->  coda.oport:  coda] 
COMPONENTS 

paraar;  Function  [...  ->  basa.ast.oport:  aat] 
analyzar.optimizar:  Function 

[basa.ast.iport :  ast ,  ...  ->  f ull_ast_oport :  ast] 
codo.gonarator:  Function 

[full.aat.iport:  aat  ->  ...] 

CONNECTORS 

baaa.aat.channal :  Dataflow. Channal [aat] 
full.aat.cbannal :  Dataf low.Channal [aat] 

CONFIGURATION 

baaa.aat.flow: 

Connocta  (baaa.aat.channal , 

baaa.aat.oport,  baaa.aat.iport) 
full.aat.flov; 

Connacta (full.aat.cbannal , 

full.aat.oport,  full.aat.iport) 

It  can  be  split  into  two  dataflow  architectures  and  Pat¬ 
tern  6  is  applied  to  each  to  construct  two  shared  memory 
architectures,  which  are  composed  horizontally  to  form  a 
single  architecture.  Then,  Pattern  3  can  be  applied  to 
merge  the  two  shared  data  structures  into  a  single  shared 
tree,  called  abstract ..syntax.tree.  The  three  architec¬ 
tures  compose  vertically,  so  we  know  that  the  final  archi¬ 
tecture,  given  below,  is  correct  with  respect  to  the  original 
dataflow  architecture. 

compiler .L2 :  MODULE 

[char.iport:  SEQ (character)  ->  code.oport:  code] 
COMPONENTS 

parser:  Function[...  ->  ] 

analyzer.optimizer:  Function[  ->  ] 

code.generator:  Function[  ->  ...] 

abstract.syntaz.tree:  Variable [ast] 

CONFIGURATION 
srite.base.ast : 

Writes (par ser ,  abstract.syntaz.tree ) 
read.base.ast : 

Reads (analyzer.optimizer,  abstract.syntaz.tree) 
srite.f ull.ast : 

Writes (analyzer.optimizer ,  abstract.syntaz.tree) 
read.f ull.ast : 

Reads (code.generator,  abstract.syntaz.tree) 
precedence.!: 

Starts.Af ter.Finish.Of (anedyzer. optimizer ,  parser) 
precedence. 2 : 

Starts.Af ter.Finish.Of (code.generator , 

analyzer.optimizer) 

C.  Development  of  the  Shared  Symbol  Table 

This  refinment  involves  three  individual  refinements,  but 
only  vertical  composition.  Consider  the  following  architec¬ 
ture,  which  specifies  the  dataflow  from  the  lexical  analyzer 
to  the  analyzer/optimizer  that  is  used  to  transmit  binding 
information. 

compiler .Ll :  MODULE 

[char.iport:  SEQ (character)  ->  code.oport:  code] 
COMPONENTS 


lezical.analyzer:  Function 
[char.iport:  SEQ (character) 

->  bind.oport:  SEQ (binding) ,  ...] 
analyzer.optimizer:  Function 

[...,  bind.iport:  SEQ(binding)  ->  ...] 

CONNECTORS 

bind.channel :  Dataf low. Channel [SEQ (binding) ] 

CONFIGURATION 

bind.flow: 

Connects (bind.channel,  bind.oport,  bind.iport) 

The  three  refinement  steps  cu:e; 

1.  Pattern  1  is  used  to  refine  the  lexical  analyzer  into 
a  new  module  containing  itself  and  a  private  symbol 
table  used  to  store  bindings  lociJly  before  proceeding 
to  the  next  phases  of  compilation,  which  could  modify 
the  table. 

2.  Pattern  6  is  used  to  introduce  a  shared  variable  be¬ 
tween  the  lexical  analyzer  and  the  optimizer,  corre¬ 
sponding  to  bind.channel,  that  can  be  used  to  trans¬ 
mit  the  completed  symbol  table. 

3.  Pattern  2  is  used  to  merge  the  private  symbol  table 
and  the  shared  variable  into  a  single  shared  repository. 
This  reflects  a  conscious  decision  to  allow  no  compo¬ 
nent  other  than  the  lexical  analyzer  to  write  the  table. 
As  a  consequence,  any  additional  information,  such  as 
storage  requirements,  and  code  restructuring  must  be 
represented  in  the  abstract  syntax  tree. 

The  resulting  architecture  is  given  below. 

coapiler_L2:  MODULE 

[char.iport:  SEQ (character)  ->  code.oport:  code] 

COMPONENTS 

lexical.analyzer.Bodule :  H0DULE[...  -*>  ...] 

COMPONENTS 

lezical.analyzer:  FunctionC. . .  *>  ...] 
symbol.table :  Variable [SEQ (binding)] 

CONFIGURATION 

vrite.bind: 

Writes (lezical.analyzer,  symbol. table) 
read.bind: 

Reads (lezical.analyzer ,  synbol.table) 

END  lezical.analyzer.Bodule 
analyzer.optimizer:  Function[  ->  ] 

CONFIGURATION 

read.bind: 

Reads (analyzer.optimizer , 

lezical.analyzer.Bodule ! symbol.table) 

D.  Putting  The  Pieces  Together 

The  three  individual  architecture  hierarchies  can  be  flat¬ 
tened  to  two  levels  because  fedthful  interpretations  are  tran¬ 
sitive.  Then,  they  can  be  composed  horizontally  to  form 
the  composite  compiler  architectures  at  levels  1  and  2.  The 
level-3  compiler  architecture  can  be  formed  in  a  similar 
fashion. 

It  is  worth  noting  that  a  series  of  refinements  can  result 
in  a  deep  hierarchy  that  need  not  be  saved  explicitly.  The 
sequence  of  steps  in  deriving  a  concrete  architecture  are 
important,  but  the  intermediate  architectures  themselves 
may  not  be.  We  saw  this  in  the  development  of  the  symbol 
table. 

^®The  nested  leiical-analyzerjnodiile  can  be  flattened  by  a  re¬ 
structuring  pattern  so  that  patterns  can  be  applied  directly. 
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We  also  observe  that  it  is  possible  to  adopt  a  hybrid  ap¬ 
proach  to  architecture  development  in  which  p^lrts  of  the 
architecture  are  developed  by  means  of  refinements  smd 
other  parts  are  specified  completely  by  hand.  In  the  lat¬ 
ter  situation,  refinement  patterns  can  be  used  to  validate 
the  correctness  of  the  putative  implementation  eurchitec- 
tures  through  a  straightforward  matching  procedure.  Cor¬ 
rect  hierarchies  Ccin  be  composed  no  matter  how  they  were 
developed,  provided  the  composition  is  faithful. 

IX.  Application  to  a  Power-Control  System 

The  approach  presented  in  this  paper  has  been  used  to 
design  an  architecture  for  an  operational  power  control  sys¬ 
tem  implemented  in  200,000  lines  of  Fortran  77  code  . 
The  system  is  used  by  Tokyo  Electric  Power  Company, 
Inc.  to  achieve  efficient  administration  of  power-supply  sys¬ 
tems  in  Tokyo,  Japan.  The  power-control  system  was  de¬ 
veloped  by  Meidensha  Corporation  auid  its  architecture  is 
considered  a  compeiny  asset.  Originally,  the  details  of  the 
architecture  were  represented  informally  in  several  loosely 
connected  documents.  This  created  a  difficult  situation 
for  Meidensha  Corp.  because  they  wanted  to  expand  their 
business  in  control  systems  to  other  areas  with  simileir  re¬ 
quirements,  which  would  require  minor  modifications  to 
the  reference  architecture.  With  no  formalized  architec¬ 
ture,  such  an  expansion  would  certainly  lead  to  duplication 
of  effort  and  unnecessary  errors  in  implementation. 

Our  objective  was  to  formalize  the  reference  architecture 
in  terms  of  company  styles  and  at  two  levels  of  detail,  and 
to  guarantee  that  the  concrete  architecture  is  correct  with 
respect  to  the  abstract  architecture.  This  taisk  was  com¬ 
pleted  successfully.  The  abstract  architecture  was  stated  in 
terms  of  a  dataflow  style,  and  the  concrete  architecture  was 
a  combination  of  a  call-return  style,  a  (structured)  shared- 
memory  style,  and  a  special  process  synchronization  style 
for  DEC  VMS  operating  systems.  Twelve  patterns  were 
used  in  the  development;  each  was  used  many  times. 

Pattern  1  vras  used  for  decomposing  functional  com¬ 
ponents  into  modules;  Pattern  6  was  used  to  implement 
dataflow  as  a  shared  variable.  Domain-specific  refinement 
patterns  were  needed  to  handle  two  distinctive  features 
of  the  concrete  power-control  architecture — heavy  use  of 
shared  memory  and  process  synchronization  by  an  enabling 
signal.  The  shared  memory  did  not  have  a  uniform  struc¬ 
ture.  Dozens  of  dataflows  were  implemented  by  a  single 
record  containing  one  field  for  each  flow.  Some  dataflows 
were  implemented  eis  a  record  structure  containing  the  data 
and  a  one-bit  enabling  signal,  and  others  as  a  message  chan¬ 
nel  plus  a  signaling  channel.  A  collection  of  veiriables  con¬ 
taining  one  bit  are  packaged  into  a  bitstring  for  efficient 
communication.  Variants  of  Patterns  2  and  3  were  used  to 
aggregate  individual  variables  into  records. 

This  successful  experience  strongly  suggests  that,  in  the 
domain  of  power  control,  only  a  small  number  of  patterns 
is  required.  This  allows  the  cost  of  pattern  verification  to 
be  amortized  across  many  applications  in  the  power-control 
domain.  We  know  that  many  of  the  patterns  are  relevant 
in  other  domains  as  well,  and  believe  that  only  a  modest 


number  of  new  patterns  will  be  needed  in  many  application 
areas. 

X.  Related  Work 

The  field  of  architecture-driven  softwfire  development 
will  not  reach  its  full  potential  until  it  is  possible  to  re¬ 
fine  and  compose  architectures  incrementally,  flexibly,  and 
in  ways  that  preserve  the  desired  properties.  Ideally,  deep 
properties  of  an  architecture,  such  as  relative  correctness, 
should  be  preserved.  This  requires  that  an  architecture  hi¬ 
erarchy  be  represented  formally  and  the  mapping  between 
the  levels  be  precise  and  explicit.  We  review  related  work 
in  the  eireas  of  refinement,  correctness,  and  composition. 

Previous  approaches  to  specification  refinement  have 
concentrated  on  the  preservation  of  functional  properties, 
which  occurs  when  the  mapping  between  specifications  is 
a  theory  interpretation.  The  mapping  often  is  complicated 
by  a  change  in  data  representation.  This  can  be  taken  into 
account  by  adapting  the  technique  of  Hoare  [12]  to  relate 
the  types  in  the  abstract  cind  concrete  specifications.  An 
analogous  problem  arises  in  architecture  refinement  when 
there  is  a  change  in  style.  We  have  introduced  the  notion 
of  a  style  mapping  to  related  the  styles  in  the  abstract  and 
concrete  architectures. 

We  are  not  the  first  to  recognize  the  importance  of 
schematic  transformations  in  stepwise  refinement.  In 
[10],  Gerhart  gives  several  examples  of  schema  transfor¬ 
mations  that  preserve  functional  correctness.  We  define 
schema  treuisformations  that  preserve  architecture  correct¬ 
ness.  The  two  forms  of  refinement  are  complementary.  An 
architecture  refinement  hierarchy  describes  system  orga¬ 
nization  —  its  components,  interfaces,  and  connections. 
Functional  refinement  is  used  to  develop  the  behavior  of 
the  system  components  in  the  architecture.  In  both  in¬ 
stances,  schemeis  can  be  used  to  increEise  the  reusability  of 
designs  and  proofs. 

Of  course,  the  utility  of  architecture  hierarchies  has  been 
recognized  for  some  time.  For  example,  in  the  1970s  Jack- 
son  [13],  Yourdan  and  Constantine  [20],  DeMarco  [7],  and 
others  describe  system  architectures  and,  more  recently,  ar¬ 
chitectural  description  has  been  the  basis  for  commercial 
offerings.  However,  previous  work  has  given  little  attention 
to  the  mapping  between  levels  of  abstraction.  We  formally 
defined  the  interpretation  mapping  required  in  architecture 
correctness  proofs  in  terms  of  a  specific  name  mapping  and 
a  general,  reusable  style  mapping.  The  mapping  also  pro¬ 
vides  the  basis  for  traceability  of  circhitectural  design  deci¬ 
sions,  which  is  useful  in  practice. 

Recently,  another  form  of  a  mapping  between  architec¬ 
tures  has  been  developed  for  the  Rapide  architecture  defini¬ 
tion  language  [14],  [15].  Rapide  is  used  to  define  executable 
architectures  based  on  distributed  event  processing.  Two 
architectures  are  related  by  mapping  concrete  events  to  ab¬ 
stract  events.  Event  mappings  provide  the  basis  for  com¬ 
parative  simulation,  a  technique  that  complements  static 
modeling. 

The  standard  criterion  for  functional  correctness  is  not 
applicable  to  architectures  because  of  the  completeness  as- 
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sumption.  A  similar  completeness  assumption  is  made 
widely  in  the  databeise  community  for  analogous  reasons, 
see  Reiter  [19].  However,  Reiter  allows  only  finitely  many 
objects,  so  a  “domain  closure  axiom”  can  be  used  to  enu¬ 
merate  the  domciin  of  discourse.  No  similar  technique  can 
be  applied  here  because,  in  general,  an  architecture  can  be 
infinite.  For  example,  we  rdlow  quantification  over  infinite 
types  (such  as  integers)  and  dynamic  architectures  with  an 
unbounded  number  of  processes  and  connections.  Because 
of  the  completeness  assumption,  an  abstract  architecture 
must  be  faithfully  interpreted  in  the  concrete  eirchitecture. 

In  [17],  Moriconi  and  Hare  study  the  relative  correctness 
of  two  architectures  under  the  completeness  assumption. 
They  make  the  simplifying  assumption  that  an  architecture 
can  contain  only  a  fixed,  finite  number  of  objects.  Broy 
[5],  Brinksma  [4],  and  others  have  applied  the  standard  ap¬ 
proach  to  correctness  to  architectures.  Broy’s  component 
refinements  turn  out  to  be  conservative  (cmd,  hence,  faith¬ 
ful)  because  interface  signatures  cire  preserved,  but  his  con¬ 
nection  refinements  may  not  be  because  additional  fiows 
could  be  added  to  a  channel.  Brinksma  justifies  channel 
splitting  on  the  basis  of  behavioral  reasoning;  application 
of  his  rule  can  violate  the  completeness  Eissumption. 

We  appeeu-  to  be  the  first  to  observe  that,  in  an  archi¬ 
tectural  correctness  proof,  it  is  important  to  establish  the 
semantic  correctness  of  the  relevant  style  mappings.  The 
importance  of  reasoning  about  connectors  was  recognized 
by  Allen  and  Garlan  [3],  who  formalize  them  in  a  subset  of 
CSP  [11]  and  then  proved  absence  of  deadlock.  In  [18]  we 
define  the  meaning  of  connectors  axiomatically  in  a  tem¬ 
poral  logic  and  prove  both  fairness  and  safety  properties 
of  an  implementation  of  the  dataflow  connector  in  shared 
memory.  Geirlan  et  al  [8],  [9]  also  have  done  importeint 
work  on  identifying  and  exploiting  architectural  styles.  We 
build  on  their  work,  developing  schematic  style  mappings 
and  schematic  refinements  involving  style-to-style  transfor¬ 
mations. 

Composition  has  been  studied  recently  by  Abadi  and 
Leimport  [1],  [2].  Their  results  are  semantic  and  applicable 
to  any  dometin,  whereas  ours  are  syntactic  and  specialized 
to  the  domain  of  software  architecture.  It  is  ecisy  to  state 
general  criteria  for  the  correctness  of  horizontal  composi¬ 
tion  of  eurchitectures.  However,  it  requires  a  difficult  proof 
that  it  is  not  possible  to  infer  new  facts  about  the  com¬ 
posite  abstract  architecture  from  the  composite  concrete 
architecture.  Therefore,  we  defined  a  new  specialized  form 
of  horizontal  composition  that  requires  only  very  simple 
syntactic  checks.  Broy  [5]  gives  three  operators  for  com¬ 
posing  functional-style  architectures,  but  does  not  consider 
the  composition  of  architectures  involving  multiple  styles. 
Vertical  composition  in  a  hierarchy  of  architectures  is  im¬ 
mediate  provided  each  level  in  the  hierarchy  is  correct  with 
respect  to  the  immediately  preceding  level. 

XI.  Conclusion 

We  have  described  a  stepwise  refinement  methodology 
for  the  development  of  a  heterogeneous  hierarchy  of  ar¬ 
chitectures  that  are  relatively  correct  under  a  particular 


completeness  eissumption.  We  introduced  the  notion  of 
an  architecture  refinement  pattern  as  the  principal  vehi¬ 
cle  for  codifying  reusable  solutions  to  routine  eirchitectural 
design  problems.  Once  an  architecture  refinement  pattern 
is  proved  correct,  instances  of  it  can  be  used  in  a  particular 
development  with  no  further  proof.  Patterns  are  compo¬ 
sitional  and  can  be  proved  in  isolation.  Subsystem  archi¬ 
tectures  are  compositional  provided  they  overlap  only  in 
certain  ways.  The  methodology  was  used  successfully  to 
explicate  the  architectural  design  of  eui  operational  power- 
control  system. 

To  develop  a  theory  of  correctness  for  architecture  refine¬ 
ment,  we  adapted  the  technique  of  faithful  interpretation 
that  was  introduced  in  an  earlier  paper  for  after-the-fact 
verification  of  complete  Mchitectures  [18].  A  new  proof 
technique  for  checking  faithfulness  was  presented.  The  in¬ 
terpretation  mapping  between  architectures  wcis  simplified 
by  decomposing  it  into  an  architecture-specific  name  map¬ 
ping  and  a  general  style-to-style  mapping.  We  are  not 
aware  of  this  distinction  being  made  elsewhere  in  the  lit¬ 
erature.  It  is  important  because  a  style  mapping  and  its 
proof,  both  of  which  can  be  complex,  can  be  reused  in  v£il- 
idating  any  pattern  involving  the  two  styles.  In  contrast,  a 
name  mapping  is  simple,  specific  to  a  pattern,  and  cannot 
be  validated  independent  of  the  pattern. 

An  important  premise  behind  our  work  is  that  at  least 
the  dominant  styles  of  architectural  design  can  be  general¬ 
ized  to  partially  interpreted  schema  and  most  architecture 
refinements  for  these  styles  can  be  generalized  to  trans¬ 
formations  on  schema.  We  believe  that  a  smetll  number 
of  architectural  styles  cire  sufficient  for  a  large  number  of 
application  domains,  and  that  only  a  modest  number  of 
refinement  patterns  are  needed  between  each  pair  of  styles. 
This  Jissertion  is  supported  to  some  degree  by  the  expe¬ 
riences  reported  in  this  paper  regarding  the  compiler  and 
power-control  architectures. 

Some  methodological  implications  of  our  faithfulness  re¬ 
quirement  are  worth  mentioning.  First,  architectural  styles 
should  clearly  differentiate  among  different  architectural 
concepts.  Consider  a  transaction  on  a  distributed  databcise 
system,  which  is  an  atomic  operation  logiccJly  but  rarely 
is  a  physically  atomic  operation.  If  the  abstract  “transac¬ 
tion”  connector  is  refined  into  a  two-phase  commit  protocol 
involving  a  series  of  data  transmissions,  the  refinement  will 
not  be  faithful  unless  the  purpose  of  the  two-pheise  commit 
is  taken  into  account  in  the  design  of  the  style.  For  exam¬ 
ple,  the  commit  protocol  can  be  modeled  in  terms  of  specied 
“control”  connectors  that  are  distinct  from  the  connector 
that  models  the  tremsfer  of  data  from  the  databcise  to  the 
designated  site.  Then,  the  abstract  flow  of  data  will  be 
the  same  as  the  concrete  flow,  even  though  there  is  extra 
preparatory  activity  in  the  concrete  architecture.  Second, 
architects  can,  but  should  not,  circumvent  the  complete¬ 
ness  assumption  by  adding  concepts  to  a  concrete  architec¬ 
ture  that  are  unrelated  to  those  in  the  associated  abstract 
architecture.  A  correctness  criterion  could  be  defined  that 
disallows  this,  but  it  would  be  too  restrictive  for  both  de¬ 
sign  eind  composition.  It  is  the  sort  of  thing  that  is  unlikely 
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to  happen  by  accident.  However,  the  only  real  safeguard  is 
the  careful  scrutiny  of  each  refinement  pattern. 

We  have  completed  an  initial  implementation  of  our 
methodology  sufficient  to  demonstrate  its  feasibility.  The 
tool  accepts  as  input  a  collection  of  refinement  patterns, 
an  abstract  architecture,  and  a  concrete  architecture.  The 
tool  matches  instances  of  the  patterns  on  the  abstract  and 
concrete  architectures  with  no  user  intervention.  It  makes 
no  attempt  to  generate  instances  at  this  time.  One  correct 
composition  of  refinements  is  found,  if  it  exists,  although  in 
general  there  may  be  many  possible  correct  compositions. 
Specific  failures  are  reported  if  there  is  not  complete  cov¬ 
erage.  Any  constraints  on  the  application  of  a  refinement 
pattern  are  checked  automatically.  This  tool  was  used  in 
the  compiler  cind  the  power-control  application. 

Future  work  involves  the  development  and  evaluation  of 
a  handbook  of  architectural  refinement  patterns.  Good  de¬ 
signers  tend  to  use  well-established  architectural  styles,  in¬ 
cluding  both  b^lsic  idioms  (such  as  pipe-filter,  client-server, 
and  layering)  and  reference  models  (such  as  the  ISO  OSI 
7-layer  model  [16]).  We  are  now  expanding  our  library 
to  relate  more  styles  as  well  as  to  elaborate  more  config¬ 
urations  involving  the  styles  in  the  paper.  Eventually,  we 
would  like  to  have  a  large  enough  library  to  support  “in¬ 
dustrial  strength”  architecture  design.  For  example,  we 
would  like  to  be  able  to  start  with  an  abstract  architec¬ 
ture  for  a  large  system,  in  say  a  dataflow  style,  refine  it 
into  architectures  in  a  dominant  commercial  style,  such 
as  client/server,  and  then  refine  that  architecture  into  an 
implementation-level  architecture  that  specifies  the  exact 
forms  of  communication.  In  developing  a  pattern  library, 
we  will  be  concerned  with  more  than  correctness.  In  par¬ 
ticular,  we  want  to  use  circhitectural  refinement  patterns 
to  achieve  a  greater  degree  of  system  predictability.  For 
example,  it  would  be  useful  to  have  refinement  patterns 
that  optimize  performance  for  specific  processors  or,  more 
generally,  for  a  given  computing  and  network  environment. 

Our  longer-term  objective  is  to  develop  a  practical  ar¬ 
chitecture  synthesis  tool  that  is  driven  by  a  broadly  useful 
pattern  libreiry.  The  tool  will  enforce  a  design  discipline 
similar  to  the  one  enforced  by  commercial  hardware  syn¬ 
thesis  tools.  These  tools  gain  much  of  their  power  from 
the  use  of  clearly  defined  and  reusable  styles:  typically, 
register-transfer,  logic,  and  gate-level  styles.  A  pattern  li¬ 
brary  of  the  sort  proposed  in  this  paper  is  expected  to 
enable  effective  synthesis  of  software  architectures. 

Appendix 

I.  Lower  Level  Compiler  Architectures 

The  textual  specifications  for  the  two  implementations  of 
the  compiler  architecture  make  extensive  use  of  imported 
types  and  styles,  which  are  not  defined  in  this  paper.  The 
specifications  have  a  straightforward  translation  into  logic. 
The  following  is  the  full  level-2  specification. 

compiler_L2:  MODULE 

[char.iport:  SEQCcharacter)  ->  code.oport:  code] 
IMPORT  character,  code,  token,  binding,  ast 
FROM  conpiler.types 


IMPORT  Function  FROM  Functional.Style 
IMPORT  Pipe,  Finite.Strean,  Connects 
FROM  Process. Pipeline.Style 
IMPORT  Variable,  Reads,  Writes 
FROM  Sheired.Memory.Style 
IMPORT  Start_After.Finish.Of 
FROM  Batch.Sequential.Style 
COMPONENTS 


lexical.analyzer.module :  MODULE 

[char.iport:  SEQ( character) 

->  token.oport:  Finite.StreamCtoken)] 
EXPORTING  lezical.analyzer ,  symbol.table 
IMPORT  character,  token,  binding 
FROM  compiler.types 
IMPORT  Function  FROM  Functional. Style 
IMPORT  Variable,  Reads.  Writes 
FROM  Shared.Memory.Style 
COMPONENTS 


lezical.analyzer:  Function 
[char.iport:  SEQ(character) 

->  token.oport :  Finite. Stream(token)] 
symbol.table:  Variable [SEQ (binding)] 
CONFIGURATION 


vrite.bind: 

Writes (lezical.analyzer,  symbol.table) 
read.bind: 

Reads (lezical.analyzer,  symbol.table) 

END  lexical. analyzer.module 
parser: 

FunctionCtoken.iport:  Finite_Stream(token)  *>  ] 
analyzer. optimizer:  Function[  *>  ] 

code. generator:  Functiont  ->  code.oport:  code] 

abstract. syntaz.tree:  Variable [ast] 

CONNECTORS 


token.pipe :  Pipe [Finite.Stream(token)] 

CONFIGURATION 

token.flov: 

Connects (token.pipe,  token.oport,  token. iport) 
read.bind: 

Reads (analyzer. optimizer , 

lexical.analyzer.module ! symbol.table) 
write. base. ast:  Writes (parser,  abstract.syntaz.tree) 
read.base.ast : 

Reads (analyzer.optimizer,  abstract.syntaz.tree) 
write. full. ast : 

Writes (analyzer.optimizer ,  abstract.syntaz.tree) 
read.f ull.ast : 

Reads (code.generator,  abstract.syntaz.tree) 
precedence.!: 

Starts.After.Finish.Of (analyzer.optimizer,  parser) 
precedence. 2: 

Starts.After.Finish.Of (code.generator , 

analyzer.optimizer) 


END  compiler.L2 


The  level-3  compiler  architecture  employs  a  common  im¬ 
plementation  of  the  batch-sequential  style.  In  particular, 
the  batch  processing  in  the  level-2  compiler  is  implemented 
in  terms  of  a  main  program  and  subroutines,  as  illustrated 
in  Figure  11.  This  implementation  is  justified  by  Pattern 
5,  which  was  presented  in  the  body  of  the  paper. 

The  wiring  at  level  3  is  constrained  by  the  temporal- 
precedence  assertions  at  level  2. 


precedence.!; 

Starts.After.Finish.Of (analyzer.optimizer,  parser) 
precedence. 2: 

Starts.After.Finish.Of (code.generator , 

analyzer.optimizer) 

We  have  to  make  sure  that  the  transfer  of  control  sat¬ 
isfies  this  temporal  ordering  of  the  computation.  Two  ap- 
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Fig.  11.  Third  level  in  architecture  hierarchy  for  compiler 


plications  of  Pattern  5  can  be  used  to  guarantee  that  the 
ordering  relations  are  satisfied  independently.  The  hori¬ 
zontal  composition  of  the  two  applications  of  Pattern  5 
guarantees  that  the  composite  architecture  satisfies  both 
orderings. 

The  composite  level-3  architecture  is  given  below. 

conpiler.LS:  NODULE 

[char.iport:  SEQ (character)  ->  code.oport:  code} 
IMPORT  character,  code,  token,  binding,  aet 
FROM  compiler.types 
IMPORT  Function  FROM  Functional. Style 
IMPORT  Pipe,  Finite. Stream,  Connects 
FROM  Process.Pipeline. Style 
IMPORT  Variable,  Reads,  Writes 
FROM  Shared.Nenory. Style 

IMPORT  Enabling.Signal,  Sender,  Receiver,  Before 
FROM  Control.Transfer. Style 
COMPONENTS 

main:  Function C  **>  ] 
lezical.analyzer.module:  NODULE 
[char.iport:  SEQ (character) 

->  token. ©port:  Finite.Stream(token)] 

EXPORTING  lezical.analyzer,  symbol.table 
IMPORT  character,  token,  binding 
FROM  compiler.types 
IMPORT  Function  FROM  Functional. Style 
IMPORT  Variable,  Reads,  Writes 
FROM  Shared.Memory.Style 
COMPONENTS 

lezical.analyzer :  Function 
[char.iport:  SEQ(character) 

->  token.oport :  Finite. Stream(token)] 
symbol.table:  Variable [SEQ (binding)] 

CONFIGURATION 

write.bind: 

Writes (lezical.analyzer ,  symbol.table) 
read.bind: 

Reads (lezical.analyzer,  symbol.table) 

END  lezical.analyzer.module 
parser: 

Function [token.iport:  Finite.Stream(token)  ->  } 
analyzer.optimizer:  FunctionC  ->  ] 

code. generator: 

Function[  ->  code.oport:  code] 
abstract. syntaz.tree :  Variable [ast] 

CONNECTORS 

token.pipe :  Pipe [Finite.Stream(token)] 

start.main,  start. lez,  start.parse,  parse. finish, 
start. opt,  opt.finish,  start. gen,  gen.finish, 
main.finish:  Enabling.Signal 
CONFIGURATION 
token.flov: 

Connects (token.pipe,  token.oport,  token.iport) 
read.bind: 


Reads (analyzer.optimizer , 

lezical.analyzer.module ! symbol.table) 
vrite.base.ast : 

Writes (parser ,  abstract. syntaz.tree) 
read.base.ast : 

Reads (analyzer.optimizer,  abstract .syntaz.tree) 
write.f ull.ast : 

Writes (analyzer.optimizer,  abstract. syntaz.tree) 
read.f ull.ast: 

Reads (code.generator ,  abstract. syntaz.tree) 
rcvr.st art .main:  Receiver (start.main,  main) 

sndr.start.lez:  Sender(start_lez,  main) 

r c vr. s t ar t . 1 ez : 

Receiver (start. lez, 

lezical.analyzer.module ! lezical.analyzer) 
sndr.start .parse:  Sender (start .parse,  main) 
rcvr.start. parse :  Receiver (start .paorse,  peurser) 
sndr.parse.f inish:  Sender (parse. finish,  parser) 
rcvr.parse.f inish:  Receiver(parse.f inish,  main) 
sndr.start. opt:  Sender (start. opt,  main) 

rcvr.start. opt : 

Receiver (start.opt,  analyzer.optimizer) 
sndr. opt.finish: 

Sender (opt .f ini sh ,  analyzer.opt imizer ) 
rcvr. opt. finish:  Receiver(opt.f inish,  main) 

sndr.start. gen:  Sender(start.gen,  main) 

rcvr.start.gen : 

Receiver (start. gen,  code.generator) 
sndr. gen.finish:  Sender (gen.finish,  code.generator) 

rcvr.gen.finish:  Receiver(gen.finish,  main) 

snrd.main.f inish:  Sender (main.finish,  main) 

start .main.before.lez : 

Before(8tart.main,  start.lez) 
start .main.before.parse : 

Before (start.main,  start.parse) 
start .parse.bef ore. finish: 

Before (start.parse,  parse. finish) 
finish.parse.bef ore. start. opt : 

Before(parse. finish,  start.opt) 
start. opt .before.f inish: 

Bef ore (start.opt ,  opt.finish) 
f inish. opt. before. start.gen: 

Before(opt. finish,  start.gen) 
start.gen.bef ore. finish: 

Before(start.gen,  gen.finish) 
f inish.gen.bef ore.main : 

Bef ore (gen.finish,  main.finish) 

END  compiler.LS 

The  associations  between  these  two  levels  are 

precedence.!  — >  finish.parse.before.start.opt 
precedence.2  — >  finish.opt.before. start.gen 
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ABSTRACT 

The  design  of  a  large  system  typically  involves  the  de¬ 
velopment  of  a  hierarchy  of  different  but  related  ar¬ 
chitectures.  A  criterion  for  the  relative  correctness  of 
an  architecture  is  presented,  and  conditions  for  archi¬ 
tecture  composition  are  defined  which  ensure  that  the 
correctness  of  a  composite  architecture  follows  from  the 
correctness  of  its  parts.  Both  the  criterion  and  the  com¬ 
position  requirements  reflect  special  considerations  from 
the  domain  of  software  architecture. 

The  main  points  are  illustrated  by  means  of  familiar 
architectures  for  a  compiler.  A  proof  of  the  relative 
correctness  of  two  different  compiler  architectures  shows 
how  to  decompose  a  proof  into  generic  properties,  which 
are  proved  once  for  every  pair  of  architectural  styles, 
and  instance-level  properties,  which  must  be  proved  for 
every  architecture. 

1  Introduction 

The  development  of  an  architecture  for  a  large  system  is 
a  complicated  task  that  can  be  made  simpler  by  means 
of  a  stepwise  development  methodology.  Ideally,  an  ar¬ 
chitect  would  use  a  hierarchical  approach  in  which  the 
composition  of  lower-level  architectures  is  guar^lnteed 
to  implement  a  higher-level  architecture.  The  founda¬ 
tions  for  such  2in  approach  must  include  a  method  for 
proving  that  one  architecture  implements  another  jir- 
chitecture  and  a  means  of  composing  architectures  so 
that  the  composite  architecture  is  correct  if  all  of  its 
components  are  correct.  We  examine  both  problems  in 

This  research  was  supported  by  the  Advanced  Reseeu-ch 
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this  paper.  We  work  at  the  logic  level,  independent  of 
a  particular  architecture  definition  language.  Thus,  our 
results  can  be  applied  to  a  large  class  of  such  languages. 

An  architecture  hierarchy  is  a  sequence  of  two  or  more 
individuad  architectures  that  may  differ  with  respect  to 
the  number  and  kind  of  objects  and  connections.  For 
example,  an  abstract  architecture  cont£dning  functional 
components  related  by  dataflow  connections  may  be  im¬ 
plemented  in  a  concrete  architecture  in  terms  of  pro¬ 
cedures,  control  connections,  and  shared  variables.  An 
abstract  architecture  usually  is  sm2dler  and  easier  to  un¬ 
derstand;  a  concrete  architecture  usually  reflects  more 
implementation  concerns.  A  given  architecture  can  be 
homogeneous  (consisting  of  one  style)  or  heterogeneous 
(consisting  of  multiple  styles).  Garlan  and  Shaw  [7] 
provide  a  taxonomy  of  some  common  styles,  including 
dataflow,  pipe-and-filter,  client-server,  and  event-based 
systems. 

Before  we  can  consider  the  relative  correctness  of  two 
architectures,  we  first  must  decide  on  the  meaning  of 
the  architectures.  Suppose  that,  to  facilitate  system 
upgrades  and  maiintenemce  on  a  p^lrticular  system,  we 
design  a  pipeline  architecture  that  restricts  the  system 
topology  to  a  linear  sequence  of  filters.  If  a  concrete 
architecture  implements  the  pipeline,  but  additionally 
introduces  feedback  loops,  the  raison  d’etre  behind  the 
original  pipeline  architecture  is  no  longer  valid.  In  ef¬ 
fect,  there  is  no  reason  to  specify  a  pipeline  in  the  first 
place  if  all  possible  feedback  loops  are  allowed  in  its 
implementation. 

Therefore,  we  make  a  completeness  assumption  about 
a  given  architecture.  Informally,  the  assumption  is  that, 
if  an  architectural  fact  is  not  explicit  in  the  architecture, 
or  deducible  from  the  eirchitecture,  then  the  fact  is  not 
intended  to  be  true  of  the  architecture.  In  the  pipeline 
example,  it  is  not  possible  to  infer  the  existence  of  a 
feedback  loop  from  the  linejirity  constraint,  so  we  as¬ 
sume  that  no  feedback  loop  is  allowed  in  am  implemen¬ 
tation  of  the  architecture.  In  general,  an  architecture 
(whether  static  or  dynamic)  can  contain  an  unbounded 
number  of  facts. 
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The  completeness  assumption  requires  a  correctness 
criterion  that  differs  from  the  standard  one  (that  is 
based  on  theory  extension).  In  our  application  of  the 
correctness  criterion,  we  maJce  a  clear  distinction  be¬ 
tween  type-level  properties  that  must  be  proved  only 
once  for  every  pair  of  architectural  styles  and  instance- 
level  properties  that  must  be  proved  for  every  pair  of 
architectures.  This  decomposition  greatly  simplifies  cor¬ 
rectness  proofs  emd  the  statement  of  the  mapping  be¬ 
tween  two  architectures.  Composition  is  possible  under 
the  completeness  2issumption  provided  that  certain  syn¬ 
tactic  constraints  are  satisfied. 

This  paper  is  organized  as  follows.  The  next  two  sec¬ 
tions  introduce  basic  architectural  concepts  and  illus¬ 
trate  the  correctness  problem  for  architectures.  Sec¬ 
tion  4  defines  the  correctness  criterion  in  terms  of  logi- 
czJ  theories,  independent  of  any  particular  architectural 
definition  language.  Sections  5-7  explain  how  to  use 
the  criterion.  Of  particular  interest  is  the  construction 
and  validation  of  the  mapping  between  architectures. 
Section  8  defines  necessary  and  sufficient  conditions  for 
architecture  composition  and  defines  two  specific  com¬ 
position  operators.  Section  9  discusses  related  work, 
and  the  conclusion  summarizes  our  results  and  discusses 
their  possible  implications  for  future  research  in  soft¬ 
ware  architecture. 


Components,  interfaces,  and  connectors  are  treated  as 
first-class  objects  —  i.e.,  they  have  a  name  and  they  are 
refineable.  Abstract  architectural  objects  can  be  decom¬ 
posed,  aggregated,  or  eliminated  in  a  concrete  architec¬ 
ture.  The  semantics  of  components  is  not  considered 
part  of  an  architecture,  but  the  semantics  of  connectors 
is. 

We  will  use  a  simple  notation  for  describing  an  ar¬ 
chitecture.  Suppose  that  we  want  to  describe  the  inter¬ 
action  between  the  parser  and  the  semantic  analyzer  in 
a  steindard  compiler.  A  dataflow  architecture  for  this 
interaction  is  contadned  in  Figure  1.^ 


peorse.analyze :  MODULE 
IMPORT  ... 

EXPORT  ... 
COMPONENTS 


parser 

analyzer 

INTERFACES 

oast 

last 


Function 

Function 

OPORT  [ast] 
IPORT  [ast] 


OF  puser 
OF  analyzer 


CONNECTORS 

ast.channel  :  Dataf low.Channel [ast] 
CONFIGURATION 

Connects (ast.channel,  oast,  iast) 

END  parse.analyze 


2  Basic  Architectural  Concepts  and  Notation 

A  software  architecture  is  represented  using  the  follow¬ 
ing  concepts. 

1.  Component:  An  object  with  independent  exis¬ 
tence,  e.g.,  a  module,  process,  procedure,  or  vari¬ 
able. 

2.  Interface:  A  typed  object  that  is  a  logical  point  of 
interaction  between  a  component  ^lnd  its  environ¬ 
ment. 

3.  Connector:  A  typed  object  relating  interface 
points,  components,  or  both. 

4.  Configmation:  A  collection  of  constraints  that 
wire  objects  into  a  specific  architecture. 

5.  Mapping:  An  relation  between  the  vocabularies 
Eind  the  formulas  of  an  abstract  and  a  concrete  ar¬ 
chitecture.  The  formula  mapping  is  required  be¬ 
cause  the  two  architectures  can  be  written  in  dif¬ 
ferent  styles. 

6.  Architectural  style:  A  style  consists  of  a  vocab¬ 
ulary  of  design  elements,  a  set  of  well-formedness 
constraints  that  must  be  satisfied  by  any  zirchitec- 
ture  written  in  the  style,  and  a  semantic  interpre¬ 
tation  of  the  connectors. 


Figure  1:  Example  Dataflow  Architecture 

The  parser  and  analyzer  are  modeled  as  functional 
components.  The  parser  (which  accepts  a  sequence  of 
tokens)  has  an  output  port  oast  that  supplies  an  ab- 
streict  syntax  tree.  The  zmalyzer  accepts  a  values  of  type 
ast  (producing  values  of  the  same  type).  The  dataflow 
connection  is  wired  to  the  right  ports  by  the  assertion 

Connects (ast-chzmnel ,  oast,  iast) 

where  Connects(c,o,i)  means  that  connection  c  links 
output  port  o  to  input  port  i.  All  of  the  objects  that 
make  up  the  aurchitecture  are  wrapped  by  a  module, 
which  can  selectively  import  and  export  objects.  In  this 
example,  we  import  some  useful  compiler  types  and  the 
predefined  functional  and  dataflow  styles. 

The  dataflow  architecture  separates  and  names  all 
components,  ports,  and  connections.  Observe  that  the 
signature  of  a  component  is  not  hard-wired  to  the  com¬ 
ponent.  A  signature  consists  of  individual  ports  that 
can  be  referenced  and  refined  independently  of  the  as¬ 
sociated  component.  Interface  separation  will  be  useful 
later  for  architecture  composition. 

*^The  precise  syntax  is  not  important  for  the  purposes  of  this 
paper.  Later,  we  formalize  this  architecture  in  logic,  and  that  is 
the  representation  that  is  intended  to  express  the  intentions  of 
the  designer. 
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3  Illustration  of  the  Problem 

Suppose  that  we  want  to  design  the  architecture  for  a 
compiler.  A  standard  dataflow  model  of  a  compiler  is 
depicted  at  the  top  of  Figure  2.  The  diagram  is  used 
only  as  an  informal  pedagogical  aid;  it  is  not  intended  to 
be  a  formal  specification.  Boxes  denote  functional  com¬ 
ponents  and  arrows  denote  directional  dataflow  between 
ports.  The  labels  on  arrows  denote  types  or  value  do¬ 
mains.  An  object  cannot  be  transmitted  between  ports 
unless  its  type  is  compatible  with  the  types  of  the  ports. 
The  diagram  is  assumed  to  be  complete  in  that  there 
can  be  no  other  functional  components,  ports,  or  data 
flows.^ 


LEVEL  1 


LudctI 

Analyzer 


-  ast  .  J 

Analyzer/ 

L»»<  .cl 

Code 

Partar 

Optimizer 

Generator  * 

•  code 


bindmgs 


LEVEL2 


write(ast) 


read(a»t) 


Lexical 
Analyzer 


/  readCaet)^^'^  vwite(a#t)  \ 


Analyzer/ 

Optimizer 


Code 

Generator 


•  code 


\rMd(bin(ing)  '| 
«wito(blnding) 


TiymWV'^' 
7^ 


^.^''read(btnding) 


[  I  functional  component  O  Inputport  - ►  dataflow  connactor 

(  )  data  structure  component  •  output  port  — pipe  connector 

. »  ordering  constraint 

— e»  read/write  connection 


Figure  2:  Two  architectures  for  a  compiler 


Figure  2  also  contains  a  concrete,  hybrid  architec¬ 
ture  for  the  compiler  that  implements  the  dataflow  style 
in  terms  of  pipe-filter,  batch-sequential,  and  shared- 
memory  styles.  Abstr2w:t  signatures  are  changed  in  the 
concrete  architecture,  dataflow  connections  are  imple¬ 
mented  in  several  ways,  through  a  pipe  and  shared  data 
objects,  and  precedence  relations  are  used  to  prevent  di¬ 
rect  flow  of  data  from  the  parser  to  the  code  generator. 

To  illustrate  the  correctness  problem,  we  focus  on 
the  implementation  of  the  dataflow  channel  between  the 
parser  and  analyzer  in  terms  of  the  reading  and  writ¬ 
ing  of  a  shared  abstract  syntax  tree.  The  implementa¬ 
tion  architecture  is  described  textually  in  Figure  3.  The 
shared  abstract  syntax  tree  is  represented  tis  a  variable.® 
The  read  and  write  relations  are  not  n£imed;  they  they 
are  primitives  that  cannot  be  refined. 


concrete_peu:se_analyze :  MODULE 

IMPORT  ... 

EXPORT  ... 

COMPONENTS 
parser 
analyzer 
tree 

CONFIGURATION 

Writes  (puser,  tree) 
Reads (analyzer,  tree) 
END  concrete_parse_analyze 


Figure  3:  Concrete  Shared-Memory  Architecture 


Function 
Variable [ast] 


The  intended  associations  between  the  two  architec¬ 
tures  are 

oast  — > 
iast  — > 

ast-channel  — >  tree 

The  first  two  associations  indicate  that  the  abstract 
ports  do  not  appear  in  the  concrete  architecture,  result¬ 
ing  in  a  new  concrete  signature  for  the  parser  and  the 
analyzer.  This  change  in  signature  reflects  the  differ¬ 
ence  between  port-to-port  communication  and  shared- 
memory  communication  by  direct  reading  and  writing  of 
a  shared  tree.  As  an  analagous  example,  consider  two 
procedures  that  communicate  through  direct  calls.  If 
we  reimplement  this  architecture  so  that  the  procedures 
communicate  only  indirectly  through  a  shared  variable, 
the  signature  of  both  procedures  would  change.  The 
third  association  says  that  dataflow  connection  is  im¬ 
plemented  by  the  abstract  syntax  tree.^ 

We  are  interested  in  three  specific  questions: 

•  Does  the  concrete  shared-memory  architecture  im¬ 
plement  the  abstract  dataflow  architecture  under 
the  completeness  assumption  and  with  respect  to  a 
given  mapping  between  architectures? 

•  Is  the  mapping  between  the  two  architectures 
meaningful?  A  relative  correctness  proof  is  only  as 
meaningful  as  the  mapping  between  architectures. 

•  Assuming  that  the  shared-memory  implementation 
of  dataflow  is  correct,  under  what  conditions  can  it 
be  composed  with  correct  implementations  of  other 
parts  of  the  compiler  to  form  a  correct  and  complete 
compiler  architecture? 


*A  dataflow  connection  is  treated  here  as  an  intransitive 
relation. 

®The  shared  abstract  syntax  tree  might  be  represented  as  an 
encapstilated  data  type  in  a  real  compiler.  If  we  had  chosen  that 
representation,  the  architecture  would  involve  calls  to  access  func¬ 
tions  that  read  and  write  the  internal  variable  used  to  represent 
the  tree. 


The  running  examples  in  the  paper  provide  a  detailed 
ainswer  to  each  of  these  questions. 

^The  tree  is  a  component.  A  component  can  be  used  to  im¬ 
plement  other  components,  or  it  can  be  used  in  conjunction  with 
connectors  to  implement  a  connection. 
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4  Formal  Criterion  of  Correctness 

Because  of  the  completeness  assumption,  we  must  prove 
not  only  that  a  concrete  architecture  does  not  lose  prop¬ 
erties  of  the  abstract  architecture,  but  also  that  no  new 
properties  about  the  abstract  architecture  can  be  in¬ 
ferred  from  the  concrete  architecture.  There  are  stan¬ 
dard  mathematical  concepts  that  can  be  used  for  this 
purpose. 

An  interpretation  mapping  is  an  association  between 
the  constants,  functions,  Jind  predicates  of  an  abstract 
and  a  concrete  theory.  An  interpretation  mapping  is 
called  a  theory  interpretation  if  the  mapped  axioms  of 
the  abstract  theory  become  theorems  of  the  concrete 
theory.  Note  that  theory  interpretation  is  just  Hoare’s 
approach  to  reasoning  about  the  correctness  of  imple¬ 
mentations  [9].  We  eidditionally  require  that,  if  a  sen¬ 
tence  is  not  in  the  abstract  theory,  its  image  is  not  in 
the  concrete  theory. 

Let  G  and  G'  be  theories  associated  with  an  abstract 
cuid  a  concrete  architecture,  respectively.  Let  /  be  an 
interpretation  mapping  from  0  to  0'.  Then,  we  must 
have,  for  every  sentence  F, 

it  FeG  then  /(F)  €  0' 

for  I  to  be  a  theory  interpretation. 

Since  we  require  that  an  eirchitecture  be  complete 
with  respect  to  a  given  level  of  detail,  we  additionally 
must  know  that  the  concrete  architecture  adds  no  new 
facts  about  the  abstract  architecture.  Therefore,  we  re¬ 
quire  that 

if  F$?0  then  I{F)  ^  G' 

This  says  that,  if  a  sentence  is  not  in  the  abstract  the¬ 
ory,  its  image  cannot  be  in  the  concrete  theory.  A  the¬ 
ory  interpretation  /  having  this  property  is  said  to  be 
a  faithful  interpretation.  Observe  that  G'  is  a  conserva¬ 
tive  extension  of  0  provided  the  identity  map  faithfully 
interprets  0  in  0'. 

Note  that  a  concrete  architecture  can  contain  facts 
not  related  to  the  abstract  architecture.  Therefore,  a 
concrete  architecture  can  introduce  new  styles  and  new 
objects.  For  example,  a  concrete  architecture  may  in¬ 
troduce  a  specification  for  part  of  the  runtime  environ¬ 
ment,  such  as  a  wrapper  for  remote  procedure  C2ills  that 
will  repine  the  stEmdard  one  provided  by  the  operating 
system. 

5  First-Order  Architectures 

We  want  to  leave  open  the  choice  of  language  for  spec¬ 
ifying  Ein  Eirchitecture.  Therefore,  we  represent  archi¬ 
tectures  as  first-order  theories,  but  our  correctness  and 
composition  results  in  no  way  depend  on  this  choice. 


The  representation  of  the  datafiow  and  the  shared- 
memory  architectures  in  Figures  1  and  3,  respectively, 
depend  on  the  styles  used  in  their  construction.  The 
dataflow-style  vocabulary  contains  predicates  for  de¬ 
scribing  functional  components,  ports,  values  associated 
with  ports,  dataflow  channels,  values  associated  with 
dataflow  channels,  and  connections  of  channels  to  ports. 
More  precisely,  the  following  sorts  denote  the  first-class 
objects  in  a  dataflow  theory:  channel,  function,  iport, 
and  oport.  We  also  make  use  of  sorts  bool  and  val,  where 
val  denotes  the  set  of  all  possible  values.  The  dataflow 
style  has  the  following  operations. 

OutPort:  oport  x  function  —y  bool 
Supplies:  oport  x  val  —y  bool 
InPort:  iport  x  function  — ►  bool 
Accepts:  iport  x  val  — ►  bool 
Carries:  channel  x  val  —y  bool 
Connects:  channel  x  oport  x  iport  bool 

The  number  of  functions,  ports,  and  channels  that  can 
appear  in  a  pEirticular  architecture  is  unbounded.  We  do 
not  bother  to  state  the  general  well-formedness  axioms 
associated  with  this  style,  or  with  others.  An  example 
of  a  general  dataflow  axiom  is  that  every  function  must 
have  at  least  one  port. 

The  shared-memory  style  uses  the  reading  and  writ¬ 
ing  of  a  variable  for  intercommunication.  Shared- 
variable  communication  is  modeled  using  a  call  site 
as  an  interface  between  a  function  and  the  shared 
variable.®  A  call  site  serves  the  same  purpose  as  a  port 
in  the  dataflow  style.  The  name  of  every  different  call 
site  must  be  unique.  The  shared-memory  style  has  the 
following  style-specific  sorts:  variable  denotes  the  set  of 
all  possible  variables  and  site  denotes  the  set  of  eill  pos¬ 
sible  call  sites  of  which  there  are  two  kinds.  The  sort 
rsite  denotes  the  sites  that  read,  or  input,  values;  the 
sort  wsite  denotes  the  ones  the  write,  or  output,  values. 
The  signature  for  the  shEired-memory  style  is 

Holds:  variable  x  val  — >  bool 
CallSite:  site  x  function  — >  bool 
Writes:  wsite  x  variable  — +  bool 
Puts:  wsite  x  val  — »  bool 
Reads:  rsite  x  variable  —y  bool 
Gets:  rsite  x  val  — >  bool 

Table  1  contains  (partial)  theories  associated  with 
the  two  architectures  in  Figures  1  and  3.  Go  denotes 
the  datafiow  theory  Eind  0m  the  shared-memory  the¬ 
ory.  Dataflow  theory  Go  says  that  the  parser  and  an¬ 
alyzer  are  functional  components,  the  parser’s  output 
port  can  supply  vEdues  of  type  ast,  the  analyzer’s  input 

®We  could  have  chosen  not  to  model  call  sites  or  some  equiv¬ 
alent  interface  object.  We  made  the  decision  in  order  to  simplify 
the  style  mapping  from  dataflow  to  shared-memory. 
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port  can  accept  values  of  type  ast,  the  dataflow  chan¬ 
nel  can  transmit  values  of  tjrpe  ast,  and  the  channel  is 
wired  to  the  ports.  The  shared-memory  theory  0m  re¬ 
places  ports  with  Call  sites,  introduces  a  variable  that 
can  hold  values  of  type  ast,  and  employs  read  and  write 
operations  on  the  variable. 

6  Mappings 

It  is  useful  to  distinguish  between  two  kinds  of  map¬ 
pings. 

•  An  name  mapping  associates  the  objects  declared 
in  an  abstract  architecture  with  objects  declared  in 
a  concrete  architecture. 

•  A  style  mapping  says  how  the  constructs  of  the 
abstract-level  style  can  be  implemented  in  terms 
of  the  constructs  of  the  concrete-level  style.  More 
speciflcally,  it  maps  all  atomic  formulas  of  the 
abstract-level  theory  to  formulas  of  the  concrete- 
level  theory. 

The  two  are  combined  to  form  an  interpretation  mai>- 
ping. 


6.1  Name  Mapping 

We  saw  a  speciflcation  of  the  intended  associations  be¬ 
tween  the  objects  in  the  two  architectures  earlier.  The 
only  difference  in  the  formal  mapping  is  that  we  intro¬ 
duce  the  implicit  call  sites.  Let  Iff  be  name  mapping 

oast  !-♦  sitei 
iast  t-+  site2 
astjchannel  tree 

which  relates  the  two  architectures.  The  domain  of  a 
name  mapping  can  be  extended  to  include  all  abstract- 
level  terms  by  mapping  variables  to  themselves. 

6.2  Style  Mapping 

Let  Is  denote  the  style  mapping  in  Figure  4  from  the 
dataflow  style  to  the  shared-memory  style.  The  U  de¬ 
note  terms,  which  in  our  examples  are  restricted  to 
logical  constants  and  variables.®  The  last  association 
specifies  the  implementation  strategy.  It  says  that  any 
instance  of  Connects{ti,t2,tz)  can  be  implemented  by 
having  call  site  t2,  corresponding  to  output  port  t2,  be 
the  interface  point  that  provides  the  values  used  in  the 
writing  of  veiriable  ti ,  corresponding  to  channel  ti .  On 
the  receiving  end  of  a  transmission,  input  port  and  call 
site  tz  serve  the  same  function.  The  other  associations 
say  that  channels  are  mapped  to  variables,  that  output 
ports  are  mapped  to  calls  that  supply  values,  and  that 

®Note  that  our  languages  contain  no  function  symbols.  A 
treatment  of  them  can  be  found  in  [6]. 


input  ports  axe  mapped  to  calls  that  receive  values.  The 
Puts  and  Gets  predicates  ensure  that  the  right  kind  of 
site  is  associated  with  the  each  kind  of  port. 


6.3  Interpretation  Mapping 

An  interpretation  mapping  I  is  determined  from  a  name 
mapping  In  and  a  style  mapping  Is,  as  follows:  for 
every  predicate  P,  all  terms  ti,t2,  -  ■  ■ ,  tn,  every  variable 
I,  and  all  formulas  F  and  G  of  the  abstract  language. 


I{P{ti,t2,...,tn)) 

I^F) 

I{F  A  G) 
I{F  V  G) 
liF  D  G) 
KyxF) 
/(3xF) 


Is{P{lN(ti),  Iwitz),  •  •  ■ )  fjv(in)) 

-^im) 

IiF)M{G) 

I{F)  V  /(G) 

I{F)  D  /(G) 

WxI{F)  ’’ 

3i/(F) 


Let  /S  denote  the  interpretation  mapping  from  theory 
0D  to  theory  0m-  Both  the  ground  facts  and  general 
axioms  in  0d  must  be  mapped.  For  example. 


I^{Connects{astjchannel,oast,  iast) 

=  Is{Connects{lN{astx.hannel), 

In  {oast).  In  {iast))) 

=  Is{Connects{tree,  sitei,  sitez)) 

=  Writes{sitei , tree)  A  Reads{site2,tree) 


which  is  the  intended  implementation. 


7  Proof  Obligations 

A  relative  correctness  proof  involves  two  steps.  First, 
we  must  prove  the  correctness  of  the  relevant  style  map¬ 
ping.  The  proof  is  performed  only  once;  it  need  not  be 
repeated  when  the  two  styles  are  used.  Second,  we  must 
demonstrate  the  relative  correctness  of  the  two  archi¬ 
tectures  with  respect  to  the  interpretatation  mapping 
formed  using  the  two  styles. 

7.1  Proof  of  a  Style  Mapping 

The  crucial  part  of  the  proof  is  concerned  with  the  va¬ 
lidity  of  the  connector  mapping.  We  would  like  to  know 
that  a  dataflow  connection  can  be  implemented  by  the 
reading  and  writing  of  a  shared  memory  location,  which 
is  modeled  as  a  variable.  This  requires  a  definition  of 
the  semantics  of  both  forms  of  connection.  We  choose 
an  axiomatic  style  of  semantic  definition  suitable  for  de¬ 
scribing  both  safety  and  fairness  properties. 

^In  general,  the  range  of  quantifiers  must  be  restricted  to  a  sub¬ 
set  of  the  concrete  domain,  see  [6].  But  no  restriction  is  required 
for  our  example,  because  every  concrete-level  object  implements 
an  abstract-level  object. 
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0D 

0M 

Function  (parser). 
Function{analyzer) 

OutPort{oast,  parser) 
'iv[Supplies{oast,v)  D  ast(t;)] 
InPort(iast,  analyzer) 

Vv[ast(u)  D  Accepts(iast,v)] 

C  hannel  (astjchannel) 

Vu[ast(i;)  D  Carries(ast.channel,v)] 
Connects(astjchannel,  oast,  iast) 

Function  (parser) 
Function(analyzer) 

V  ariable(tree) 

Vi;[asi(u)  D  Holds(tree,  u)] 
CallSite(sitei ,  parser) 
'dv[Puts(sitei,v)  D  ast(u)] 
Writes(parser,  tree) 
CallSite(site2,  analyzer) 
Vi;[ost(i;)  D  Gets(site2,v)] 
Reads(analyzer,  tree) 

Table  1:  Partial  Dataflow  and  Shared-Memory  Theories 


Functi(m{t\) 
OutPort{ti,t2) 
Supplies(ti,t2) 
InPort{ti,t2) 
Accepts{ti,t2) 
Channel(ti) 
Carries{ti,t2) 
Connects  (t  i ,  *2 1  ^3 ) 


Function{ti) 

CallSite{ti, <2)  A  u) 

Puts{ti,t2) 

CallSite{ti,t2)  A  3vGets{ti,v) 
Gets{t\,t2) 

Variable{ti) 

Holds{ti,t2) 

Writes{t2,t\)  A  Reads{t3,t\) 


Figure  4:  A  Style  Mapping 


In  particular,  we  use  a  temporal  logic,  called  the  Tem¬ 
poral  Logic  of  Actions  (TLA)  [11],  to  define  dataflow 
and  sheired-memory  communication: 

•  The  semantics  of  dataflow  places  minimal  restric¬ 
tions  on  communication.  It  says  that  a  multiset  of 
values  is  treinsmitted  between  components.  Values 
C£in  be  “lost”  and  out  of  order.  The  fairness  con¬ 
dition  is  that  eventually  a  send  or  receive  occurs 
unless  both  are  impossible.  One  reason  for  impos¬ 
sibility  could  be  failure  of  the  communications  line. 

•  The  semantics  of  shared  memory  requires  that 
tranmission  preserve  ordering  and  that  values  can¬ 
not  be  lost.  The  fairness  condition  is  that  all  values 
written  into  shared  memory  will  eventually  be  read 
from  the  memory  if  it  is  possible  to  read  them. 

For  comparison  purposes,  the  appendix  contains  an  op¬ 
erational  definition  of  the  two  forms  of  communication 
in  standard  CSP  [8],  following  Allen  and  Garlan  [2]. 
CSP  can  be  used  to  model  the  safety  properties,  but 
not  the  fairness  properties. 

We  formalize  the  semantics  of  dataflow  and  shared- 
memory  connections  as  TLA  theories.  We  deflne  an 
interpretation  mapping  from  the  dataflow  seman¬ 
tics  to  the  shared-memory  semantics  and  show  that  it 
is  a  theory  interpretation.  This  is  sufficient  to  establish 


that  dataflow  can  be  implemented  with  a  single  shared 
memory  location  and  that,  if  the  shared-memory  com¬ 
munication  is  fair,  the  dataflow  communication  is  fair. 
We  make  use  of  the  following  TLA  notation. 


Notation 

Meaning 

/ 

list  of  variables  in  the  old  state 

/' 

list  of  variables  in  the  new  state 

A 

action — relation  between  old  and  new  states 

Enabled 

possible  to  perform  action 

lAf 

Av(f'  =  f) 

{^)j 

A/\(f'^f) 

OF 

always  F 

OF 

-iD-iF  (sometimes  F) 

WF/(.4) 

□0(>l)/  V  OO-iEnabled  {A)f 

The  last  line  says  that  eventually  action  A  must  either 
be  taken  or  become  impossible  to  take.  For  example,  a 
precondition  for  execution  may  not  be  satisfiable. 

In  the  proof,  we  make  use  of  two  TLA  inference  rules. 


STL4. 


FdG 
OF  D  DG 


where  F  eind  G  are  temporal  formulas,  says  that,  if  F 
implies  G,  the  always  F  implies  always  G. 


TLA2. 


[g], 

a[A]f  D  u[B]g 
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is  a  simplification  of  Lamport’s  TLA2  axiom  that  suf¬ 
fices  for  our  purposes.  It  says  that,  if  action  A  implies 
B,  then  always  A  implies  eilways  B. 

Figures  5  and  6  contain  the  TLA  theories  of  datafiow 
and  shared-memory,  respectively.  The  quoted  boldface 
symbols  are  logical  constants.  In  Figure  5,  the  datafiow 
connector  is  denoted  by  the  flow  state  function,  which 
is  a  multiset,  with  three  operators:  with  is  the  insertion 
operator,  less  is  the  deletion  operator,  and  choose  is 
used  to  select  an  element  firom  a  nonempty  multiset. 
Values  carried  by  the  connector  must  be  in  set  Type, 
the  set  of  all  possible  values.  The  dataflow  semantic 
theory  is  defined  to  be  $,  which  says  three  things:  the 
dataflow  has  to  start  in  the  initial  state,  it  must  always 
be  possible  to  perform  a  send  or  a  receive  operation,  and 
the  communication  line  eventually  responds  to  send  and 
receive  requests  if  it  is  possible  to  do  so  (fairness).  The 
shared-memory  semantic  theory,  called  ,  is  defined  in 
a  similar  manner. 


Initit 

def 

A 

ev  =  “ready” 
flow  =  “emptybag' 

^sender 

A 

ev  =  “ready” 
ev'  =  “send” 

A 

flow'  =  flow 
val'  €  Type 

A 

T^receiver 

ev  =  “ready” 

A  ev'  =  “receive” 
A  flow'  =  flow 
A  val'  =  val 


Sfi 


OW 


Hfi 


OW 


•hfflow 

AT 


w 

$ 


ev  =  “send” 

A  ev'  =  “ready” 

A  flow'  =  flow  with  vdl' 
A  val'  =  val 

ev  =  “receive” 

A  ev'  =  “ready” 

A  flow  7^  “emptybag” 
A  val'  =  choose{flow) 

A  flow'  =  flow  less  val' 


def 

(^f 

def 


Sfi  OW  VTlfi  OW 

^ flow  V  Sg^nder  V  72-  receiver 
{ev,  val,  flow) 

{3flow){Initi  A  □[A/lu^  A  WF„,(A/'/;ou,)) 


Figure  5:  Semantics  of  Dataflow 


Interpretation  mapping  maps  constants,  state 
functions,  and  operators  of  the  datafiow  semantics  to 
those  of  the  shared-memory  semantics.  ^  is  defined 
by 


Jfiit'ip 

4®^ 

A 

op  =  “ready  .write” 
mem  =  “undefined” 

^^writer 

4®f 

A 

op  =  “ready  .write” 
op'  =  “write” 

A 

mem'  =  mem 

<^f 

A 

val'  G  Type 

'^reader 

A 

op  =  “ready  jread” 
op'  =  “read” 

A 

mem'  =  mem 

A 

val'  =  val 

Wmem 

<^f 

A 

op  =  “write” 
op'  =  “ready  jead” 

A 

mem'  =  val' 

A 

val'  =  val 

TZmem 

^f 

A 

op  =  “read” 

op'  =  “ready  .write” 

A 

mem  ^  “undefined” 

A 

mem'  =  val' 

A 

val'  =  mem 

*^mem 

— ^  W  V  72, 

““  ^f'mem  v  /Vmem 

M 

d©f 

=  Almcm  V  y^writer  V  Tireader 

u 

=  {op,  val,  mem) 

/nttvp  A  n[M]u  A  WF„(M,„e,„) 

Figure  6:  Semantics  of  Shared  Memory 


ev 

op 

flow 

1— ► 

mem 

“emptybag” 

“undefined” 

“ready” 

)—¥ 

either  ( “ready  .write” , 
“ready  jead”) 

“send” 

!—► 

“write” 

“receive” 

► 

“read” 

ti  with  <2 

1— ► 

t2 

ti  less  t2 

*2 

choose{ti) 

1— > 

tl 

where  ti  and  t2  are  terms 

.  The  last  three  associations 

interpret  multiset  operations  in  the  context  of  our  spe¬ 
cific  weadc  fairness  condition  on  sheired  memory. 

To  show  that  is  a  theory  interpretation,  we  need 
to  prove  that  4'  D  The  first  step  is  to  prove 

that 

Init^  D  y°{Initi).  (1) 

Applying  to  /nit$  we  get: 

op  =  ettfter( “ready .write”,  “ready jread” ) 

A  mem  =  “undefined” . 

Hence  (1)  holds.  The  second  step  is  to  show  that 

(2) 
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We  can  easily  show  that 


Wttfritcr 

3 

(S sender) 

(3) 

Threader 

D 

(Tireceiver) 

(4) 

Wmcm 

D 

^(Sflow) 

(5) 

T^mem 

D 

•^(J^flow) 

(6) 

from  which  we  infer  that 

[M\u  3  ([AHu-)- 

Applying  rule  TLA2,  we  conclude  that  (2)  holds.  The 
third  step  is  to  show  that 

WF„(Mmem)  3  (WF,„(A/>jo«,))-  (7) 

From  (3)-(6),  we  get 

(Admem)ii  3  ^^{{Mflow)w)- 

Applying  rule  STL4  twice  and  the  definition  of  O,  we 
get 

□0(A4  mcm)« 

From  the  definition  of  Enabled,  we  have 

Enabled  3  Enabled  {M  mem)u' 

Since 

(Enabled  {Affiow)w)  3  Enabled  -^?r((A//jou))tii)) 
we  apply  rule  STL4  to  get 

DO-nEnabled  {Mmem)u  3  (Enabled  (Mfiow)w), 

from  which  we  conclude  that  fairness  condition  (7) 
holds. 

7.2  Relative  Correctness  Proof 

We  must  show  that  is  a  theory  interpretation  and 
that  it  is  faithful.  A  proof  of  the  former  is  straightfor¬ 
ward.  For  example,  under  the  axiom 

Connects(ast -channel,  oast,  last) 

is  interpreted  as 

Wrfres(porser,  tree) 

A  Reads(analyzer,  tree) 

which  is  a  theorem  that  follows  directly  from  0m- 
To  show  faithfulness,  notice  that  induces  a  map¬ 
ping  /'  from  shared-memory  structures  to  dataflow 
structures  as  follows.  If  maps  atomic  dataflow  for¬ 
mula  P(x)  to  shared-memory  formula  F,  then  I'  assigns 
to  dataflow  predicate  P  the  set  of  shared-memory  tuples 
that  satisfy  F. 

Given  a  model  D  of  0d,  we  can  construct  a  model  M 
of  0M  as  follows.  The  universe  of  M  is  the  same  as  D. 
The  assignment  to  predicates  by  M  is  defined  as: 


Function  =  {a  £  |D|  :  D  ^  Function(a)} 
Variable  =  {a  G  jf?!  :  |=  Channel(a)} 

Writes  =  {(a,  6)  G  \D\^  :3c,de  \D\ 

[D  1=  OutPort(c,  a)  A 
Connects(b,  c,  d)]} 


By  a  theorem  stated  in  [15]  and  proved  in  [16],  the 
fact  that  induced  mapping  I'  maps  M  back  to  D  is 
enough  to  conclude  that  is  faithful. 

8  Composing  Architectures 

A  useful  form  of  architecture  composition  is  illustrated 
in  Figure  7.  We  want  to  compose  two  architectures, 
called  “subsystem  A”  and  “subsystem  B”,  into  a  single 
system  architecture.  We  construct  a  new  architecture 
with  components  “A”  and  “B”  connected  through  new 
interfaces.  If  two  conditions  are  satisfied,  the  three  ar¬ 
chitectures  can  be  combined  to  form  a  composite  system 
that  is  correct  if  the  three  subsystems  are. 


Figure  7:  Illustration  of  Subsystem  Composition 


Let  01  and  02  be  theories  that  represent  two  abstract 
architectures.  Let  0i  and  02  be  concrete  theories  in¬ 
tended  to  implement  0i  and  02,  respectively.  Two  pairs 
of  architecture  theories  can  be  composed  only  in  ways 
that  preserve  faithfulness.  More  precisely,  if 

Ji:  01  — »  01  and  I2'  ®2 

are  faithful  interpretations,  then  we  want 

h  U  h-  01  U  02  ^  0i  U  02 

to  be  a  faithful  interpretation.  (The  union  of  two  the¬ 
ories  is  the  deductive  closure  of  the  set-theoretic  union 
of  the  theories.) 

This  property  holds  provided  two  general  conditions 
are  satisfied. 
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1.  The  composite  interpretation  mapping  must  be  a 
function.  For  a  sentence  F,  we  require  that 

VFe0in02  [ii{F)  =  hiF)] 

which  guarantees  that  interpretation  mappings  /i 
and  I2  agree  on  shared  objects  and  shared  style 
constructs. 

2.  It  must  not  be  possible  to  infer  new  facts  about  the 
composite  abstract  architecture  from  the  composite 
concrete  architecture.  That  is,  for  language  Li  of 
01  and  Z/2  of  02,  if 

F  is  a  sentence  of  Li  U  L2 
£ind 

6[  U  0^  h  I{F) 
then  we  must  prove  that 

/(0i)U7(02)bJ(F). 

The  intuition  behind  the  second  condition  can  be  il¬ 
lustrated  by  means  of  a  simple  example.  Consider  an  ar¬ 
chitecture  in  which  there  is  a  dataflow  connection  from 
AtoB  and  another  architecture  that  has  dataflow  con¬ 
nection  from  B  to  C.  Suppose  that  both  flows  are  im¬ 
plemented  correctly  in  concrete  architectures,  but  that 
in  one  A  writes  some  v^lriable  x  and  in  the  other  C  reads 
a  variable  x.  Each  implementation  is  correct,  since  nei¬ 
ther  introduces  a  new  dataflow.  However,  the  composite 
concrete  architecture  reads  and  writes  x,  from  which  we 
can  infer  an  entirely  new  abstract  dataflow  connection 
from  A  to  C.  Consequently,  the  composite  abstract  8U‘- 
chitecture  is  not  faithfully  interpreted  (by  the  composite 
mapping)  in  the  composite  concrete  architecture  (under 
the  original  assumption  that  dataflow  is  intransitive). 

Although  the  second  condition  is  a  rather  strong  log- 
icedly,  it  appears  to  be  flexible  enough  for  architecture 
composition.  The  form  of  composition  illustrated  in 
Figure  7  can  be  handled  easily  by  allowing  two  abstract 
^lrchitectures  to  share  only  one  component  cind  possibly 
its  interface  points.  Styles  can  be  shared  but  no  other 
objects.  These  constraints  guaraintee  that  the  two  con¬ 
ditions  above  eure  satisfied,  and  the  desired  composition 
can  be  performed  in  two  steps. 

Another  useful  form  of  composition  is  the  cheiining 
together  of  a  sequence  of  correct  architectures.  Since 
fzdthful  interpretation  is  transitive,  intermediate  archi¬ 
tectures  can  be  omitted  in  the  development  of  a  concrete 
architecture.  Intermediate  architectures  eirise  because 
we  make  explicit  all  important  intermediate  steps  in  a 
development,  even  if  they  correspond  to  small  architec¬ 
tural  changes.  The  intermediate  architectures  need  not 
be  explicit  as  long  as  there  is  a  sequence  of  instsinces 


of  refinement  patterns  that  connect  the  first  (most  ab¬ 
stract)  and  laist  (most  concrete)  architectures  in  the  se¬ 
quence. 

We  return  to  the  compiler  architecture  in  Figure  2 
to  give  a  specific  example  of  composition.  We  proved 
that  the  dataflow  connection  between  the  parser  and 
the  analyzer  is  implemented  correctly  by  means  of  the 
reading  £ind  writing  of  the  tree.  That  is,  we  showed  that 
dateiflow  theory  0d  is  implemented  correctly  by  theory 
0M  with  respect  to  mapping  I^.  Similarly,  we  can  show 
that  the  dataflow  connection  from  the  lexical  analyzer  to 
the  parser  is  correctly  implemented  by  the  pipeline  con¬ 
nection  in  the  concrete  architecture.  The  two  abstract- 
concrete  pairs  of  architectures  share  a  common  com¬ 
ponent,  the  pEirser,  but  no  interface  points.  Therefore, 
our  second  condition  is  satisfied  and  we  can  compose  the 
two  pairs  directly.  (The  two  mappings  are  constructed 
to  meet  the  first  condition.)  No  linking  architecture  is 
needed. 

9  Related  Work 

The  utility  of  architecture  hierarchies  was  recognized 
in  the  1970s,  but  architecture  hierarchy  was  studied 
only  informally  at  that  time.  Several  notations  were 
developed  for  describing  architectures,  including  those 
of  Jackson  [10],  Yourdan  and  Constantine  [17],  and  De¬ 
Marco  [5],  but  little  attention  was  given  to  understand¬ 
ing  the  relationship  between  levels  of  abstraction. 

Moriconi  and  Hare  [14]  formalized  a  relationship  be¬ 
tween  levels  in  a  hierarchy  and  used  the  technique  of 
Hoare  [9]  to  prove  the  relative  correctness  of  two  stylisti¬ 
cally  different  architectures.  Hoaire’s  technique  involves 
a  proof  of  only  theory  interpretation,  and  not  of  fjiithful- 
ness.  They  were  the  first  to  introduce  a  completeness  as¬ 
sumption  for  architectures.  An  architecture  wais  allowed 
to  contain  only  finitely  many  objects  (constants),  which 
enabled  them  to  fully  mechainize  correctness  proofs.  The 
completeness  assumption,  as  formalized  in  this  paper, 
applies  equailly  well  to  infinite  architectures.  For  exam¬ 
ple,  it  is  possible  to  quantify  over  infinite  types  (such 
as  integers)  and  to  reason  about  dynamic  architectures 
with  an  unbounded  number  of  processes. 

The  technique  of  Hoare  has  been  applied  more  re¬ 
cently  to  eurchitecture  by  Broy  [4],  Brinksma  [3],  and 
others.  Broy’s  component  refinements  turn  out  to  be 
conservative  because  interface  signatures  are  preserved, 
but  his  connection  refinements  may  not  be  because  ad- 
ditionail  flows  could  be  added  to  a  channel.  Brinksma 
justifies  channel  splitting  on  the  basis  of  behavioral  rea¬ 
soning;  application  of  his  rule  can  violate  the  complete¬ 
ness  assumption. 

A  Hoeire-style  representation  mapping  has  been  ap¬ 
plied  to  dynamic  architectures  by  Luckham  et  al  [12, 13]. 
A  language  called  Rapide  is  used  to  define  executable  ar- 
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chitectures  based  on  distributed  event  processing.  Map¬ 
pings  relate  concrete  events  to  abstract  events  and  are 
used  as  the  basis  for  comparative  simulation,  a  tech¬ 
nique  that  complements  ours. 

The  problem  of  composition  of  specifications  has  been 
studied  in  a  general  semantic  framework  by  Abadi  and 
Lamport  [1].  Their  results  are  applicable  to  any  do¬ 
main,  whereas  our  results  are  syntactic  and  specialized 
to  the  domain  of  software  architecture.  The  advantage 
of  a  syntactic  constraint  is  that  it  can  be  checked  eas¬ 
ily.  The  disadvantage  is  that  it  is  more  restrictive  than 
semantic  composition.  Broy  [4]  gives  three  operators 
for  composing  functional-style  architectures,  but  does 
not  consider  the  composition  of  architectures  involving 
multiple  styles. 

10  Conclusion 

An  architecture  for  a  large,  complex  system,  and  even 
some  simple  systems,  will  involve  multiple  levels  of  de- 
teul  expressed  in  multiple  architectural  styles.  The  novel 
contributions  of  the  work  reported  here  are: 

•  A  formal  criterion  for  proving  that  one  architecture 
implements  another  architecture,  even  if  they  are 
described  in  diflFerent  architectural  styles.  A  change 
in  the  representation  of  a  component,  an  interface, 
or  a  connector  is  handled,  but  a  change  in  the  rep¬ 
resentation  of  a  type  requires  a  slightly  different 
criterion. 

•  A  decomposition  of  the  mapping  between  architec¬ 
tures  into  type-level  properties  that  ^lre  proved  once 
for  every  pair  of  styles  and  instance-level  properties 
that  Me  proved  for  every  paiir  of  architectures.  The 
importance  of  this  decomposition  was  underscored 
by  a  proof  that  the  connectors  of  a  common  con¬ 
crete  style  implement  the  connectors  of  a  common 
abstract  style.  The  proof  was  somewhat  compli¬ 
cated,  estaWishing  both  safety  eind  fairness  proper¬ 
ties,  but  it  does  not  need  to  be  repeated  each  time 
the  styles  Me  used. 

•  Syntactic  criteria  for  composing  Mchitectures  such 
that  the  composition  of  two  correct  architectures  is 
correct.  One  specific  composition  operator,  which 
is  useful  for  putting  together  subsystems,  allows 
two  Mchitectures  to  be  composed  provided  they 
shMe  only  components  and  their  interface  points. 
Another  composition  operator  is  used  to  eliminate 
intermediate  levels  in  an  architecture  hierarchy. 

Our  approach  applies  to  any  logic  used  to  represent  an 
Mchitecture;  it  does  not  depend  on  a  particulM  Mchi- 
tecture  definition  language  or  a  particulM  kind  of  con¬ 
nector  semantics.  A  more  comprehensive  treatment  of 


the  formal  techniques  in  this  paper  can  be  found  in  a 
companion  paper  [15]. 

The  work  reported  here  may  have  implications  in  sev¬ 
eral  subMeas  of  software-architecture  research. 

•  Language  design.  An  Mchitecture  definition  lan¬ 
guage  (ADL)  should  treat  all  refineable  objects, 
including  components,  interface  points,  and  con¬ 
nectors,  as  first-class  in  the  sense  that  they  should 
be  named  objects  with  independent  meaning.  An¬ 
other  implication  is  that  an  ADL  should  make  it 
impossible  to  subvert  the  completeness  assumption. 
For  example,  an  ADL  type  system  should  not  al¬ 
low  components  to  be  values,  which  would  allow 
interactions  to  be  created  indirectly.  The  last  im¬ 
plication  is  that  an  ADL  should  support  the  spec¬ 
ification  of  two  kinds  of  mappings:  style  mappings 
and  name  mappings  between  architectures. 

•  Refinement  methodology.  It  seems  clear  that 
after-the-fact  proof  of  an  Mchitecture  hierMchy  will 
be  very  difficult.  This  is  true  primMily  because 
of  the  need  to  establish  conservativeness  (mod¬ 
ulo  renaming).  An  incremental  development  strat¬ 
egy  that  minimizes  the  number  and  difficulty  of 
Mchitecture-specific  proofs  is  needed.  One  candi¬ 
date  approach  involving  correctness-preserving  ar¬ 
chitectural  transformations  is  described  in  [15]. 

•  Style  design.  Styles  are  an  important  vehicle 
for  organizing  reusable  architectural  design  infor¬ 
mation.  We  showed  that  the  specification  of  style 
mappings  is  a  key  element  of  style  design,  and  that 
the  semantics  of  a  style  can  be  affected  by  how  the 
style  is  intended  to  be  used  in  relation  to  other 
styles. 
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A  Proof  of  Connector  Mapping  in  CSP 

We  can  define  the  semantics  of  the  dataflow  and  shared 
memory  styles  in  CSP  [8],  following  Allen  and  Garlan 
[2].  We  make  use  of  the  following  CSP  notation. 


Notation 

aP 

P\\Q 

a^P 

a^P\b^Q 

P\C 

f-.A^B 


Meaning 

the  alphabet  of  process  P 
P  in  parallel  with  Q 
a  then  P 

a  then  P  choice  b  then  Q  (a  ^b) 
P  without  C  (hiding) 

/  is  a  function  mapping  A  to  P 


We  also  make  use  of  the  count  process  CT,  defined 
as  follows. 


CTo  =  {up CTi\around CTo) 

CTn+i  =  {up  —y  CTn+2\down  —y  CTn) 

The  CSP  semantics  is  essentially  the  same  as  the  TLA 
semantics.  However,  a  connector  is  modeled  directly 
in  TLA  by  a  state  function.  It  is  modeled  indirectly 
in  CSP  as  a  process,  which  essentially  computes  the 
state  function.  Standard  CSP  cannot  be  used  to  express 
fairness  of  the  kind  in  our  example.  Therefore,  we  prove 
only  safety. 


The  CSP  semantics  for  the  datafiow  style  is 


DFS 

= 

Sender  ||  Receiver  ||  Flow 

aSender 

= 

{oport} 

Sender 

= 

oport  ~y  Sender 

aReceiver 

{iport} 

Receiver 

= 

iport  Receiver 

aFlow 

= 

{oport,  iport} 

Flow 

= 

(CToll  Flow’)\{around,  down,  up} 

aFlow’ 

{around,  down,  up,  oport,  iport} 

Flow’ 

oport  -»  up  Flow’ 

1  around  —y  Flow’ 

1  down  —y  iport  — »  Flow’ 

and  the  CSP  semantics  for  the  shared-memory  style 

SMS 

= 

Writer  ||  Reader  ||  Var 

aWriter 

= 

{write} 

Writer 

= 

write  -+  Writer 

aReader 

= 

{read} 

Reader 

= 

read  — ►  Reader 

aVar 

= 

{write,  read} 

Var 

= 

write— >  read  — >  Var 

We  must  show  that  the  shared-memory  style  is  a  cor¬ 
rect  implementation  of  the  dataflow  style.  Intuitively, 
every  behavior  of  the  shared-memory  style  should  cor¬ 
respond  to  an  allowable  behavior  of  the  dataflow  style. 
Since  the  alphabets  of  the  two  styles  are  different,  this 
can  be  done  using  the  CSP  change-of-symbol  operator 
f:  f  {write)  =  oport  eind  f{read)  =  iport.  Hence,  the 
correctness  proof  amounts  to  showing  that  f{SMS)  C 
DFS,  which  is  straightforward. 
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